摘要：將截獲的密文用自己偽造證書的私鑰解開，獲得并計算得到通信用的對稱密鑰。

為何要用https?

http協(xié)議的缺點

• 通信使用明文，內(nèi)容可能被竊聽(重要密碼泄露)
• 不驗證通信方身份，有可能遭遇偽裝(跨站點請求偽造)
• 無法證明報文的完整性，有可能已遭篡改(運營商劫持)

用https能解決這些問題么？

https是在http協(xié)議基礎(chǔ)上加入加密處理和認(rèn)證機制以及完整性保護，即http+加密+認(rèn)證+完整性保護=https
https并非應(yīng)用層的一種新協(xié)議，只是http通信接口部分用ssl/tls協(xié)議代替而已。通常http直接和tcp通信，當(dāng)使用ssl時則演變成先和ssl通信，再由ssl和tcp通信。
所謂https，其實就是身披ssl協(xié)議這層外殼的http

SSL/TLS是什么？

SSL 是“Secure Sockets Layer”的縮寫，中文叫做“安全套接層”。它是在上世紀(jì)90年代中期，由網(wǎng)景公司設(shè)計的。
為啥要發(fā)明 SSL 這個協(xié)議？因為原先互聯(lián)網(wǎng)上使用的 HTTP 協(xié)議是明文的，存在很多缺點——比如傳輸內(nèi)容會被偷窺（嗅探）和篡改。發(fā)明 SSL 協(xié)議，就是為了解決這些問題。
到了1999年，SSL 因為應(yīng)用廣泛，已經(jīng)成為互聯(lián)網(wǎng)上的事實標(biāo)準(zhǔn)。IETF 就在那年把 SSL 標(biāo)準(zhǔn)化。標(biāo)準(zhǔn)化之后的名稱改為 TLS（是“Transport Layer Security”的縮寫），中文叫做“傳輸層安全協(xié)議”。
所以這兩者其實就是同一種協(xié)議，只不過是在不同階段的不同稱呼。

SSL協(xié)議位于TCP/IP協(xié)議與各種應(yīng)用層協(xié)議之間，為數(shù)據(jù)通訊提供安全支持。SSL協(xié)議可分為兩層：
SSL記錄協(xié)議（SSL Record Protocol）：它建立在可靠的傳輸協(xié)議（如TCP）之上，為高層協(xié)議提供數(shù)據(jù)封裝、壓縮、加密等基本功能的支持。
SSL握手協(xié)議（SSL Handshake Protocol）：它建立在SSL記錄協(xié)議之上，用于在實際的數(shù)據(jù)傳輸開始前，通訊雙方進行身份認(rèn)證、協(xié)商加密算法、交換加密密鑰等。

對稱秘鑰加密和非對稱秘鑰加密

對稱密鑰加密，又稱私鑰加密，即信息的發(fā)送方和接收方用同一個密鑰去加密和解密數(shù)據(jù)。它的最大優(yōu)勢是加/解密速度快，適合于對大數(shù)據(jù)量進行加密，但密鑰管理困難。
非對稱密鑰加密，又稱公鑰加密，它需要使用一對密鑰來分別完成加密和解密操作，一個公開發(fā)布，即公開密鑰，另一個由用戶自己秘密保存，即私用密鑰。信息發(fā)送者用公開密鑰去加密，而信息接收者則用私用密鑰去解密。
從功能角度而言非對稱加密比對稱加密功能強大，但加密和解密速度卻比對稱密鑰加密慢得多。
非對稱密鑰通信過程

SSL/TLS協(xié)議基本原理

SSL/TLS協(xié)議的基本思路是采用公鑰加密法，也就是說，客戶端先向服務(wù)器端索要公鑰，然后用公鑰加密信息，服務(wù)器收到密文后，用自己的私鑰解密，但是這里有兩個問題：
（1）、如何保證公鑰不被篡改？
解決方法：將公鑰放在數(shù)字證書中，只要證書是可信的，公鑰就是可信的。
（2）、公鑰加密計算量太大，如何減少耗用的時間？
解決方法：每一次對話（session），客戶端和服務(wù)器端都生成一個"對話密鑰"（session key），用它來加密信息。由于"對話密鑰"是對稱加密，所以運算速度非?？?，而服務(wù)器公鑰只用于加密"對話密鑰"本身，這樣就減少了加密運算的消耗時間。

因此，SSL/TLS協(xié)議的基本過程是這樣的：

1. 客戶端向服務(wù)器端索要并驗證公鑰。
2. 雙方協(xié)商生成“對話密鑰”。
3. 雙方采用“對話密鑰”進行加密通信。

具體過程可參考下面的栗子
假定客戶端叫做愛麗絲，服務(wù)器叫做鮑勃，整個握手過程可以用下圖說明

第一步，愛麗絲給出協(xié)議版本號、一個客戶端生成的隨機數(shù)（Client random），以及客戶端支持的加密方法，具體的加密方法可參考SSL證書背后的加密算法。
第二步，鮑勃確認(rèn)雙方使用的加密方法，并給出數(shù)字證書、以及一個服務(wù)器生成的隨機數(shù)（Server random）。
第三步，愛麗絲確認(rèn)數(shù)字證書有效，然后生成一個新的隨機數(shù)（Premaster secret），并使用數(shù)字證書中的公鑰，加密這個隨機數(shù)，發(fā)給鮑勃。
第四步，鮑勃使用自己的私鑰，獲取愛麗絲發(fā)來的隨機數(shù)（即Premaster secret）。
第五步，愛麗絲和鮑勃根據(jù)約定的加密方法，使用前面的三個隨機數(shù)，生成"對話密鑰"（session key），用來加密接下來的整個對話過程。

HTTPS工作原理

1、客戶端發(fā)起HTTPS請求
用戶在瀏覽器里輸入一個https網(wǎng)址，然后連接到server的443端口。
2、服務(wù)端的配置
采用HTTPS協(xié)議的服務(wù)器必須要有一套數(shù)字證書，可以自己制作，也可以向組織申請，區(qū)別就是自己頒發(fā)的證書需要客戶端驗證通過，才可以繼續(xù)訪問，而使用受信任的公司申請的證書則不會彈出提示頁面。
3、傳送證書
這個證書其實就是公鑰，只是包含了很多信息，如證書的頒發(fā)機構(gòu)，過期時間等等。
4、客戶端解析證書
這部分工作是由客戶端的TLS來完成的，首先會驗證公鑰是否有效，比如頒發(fā)機構(gòu)，過期時間等等，如果發(fā)現(xiàn)異常，則會彈出一個警告框，提示證書存在問題。
（1）首先瀏覽器讀取證書中的證書所有者、有效期等信息進行一一校驗
（2）瀏覽器開始查找操作系統(tǒng)中已內(nèi)置的受信任的證書發(fā)布機構(gòu)CA，與服務(wù)器發(fā)來的證書中的頒發(fā)者CA比對，用于校驗證書是否為合法機構(gòu)頒發(fā)
（3）如果找不到，瀏覽器就會報錯，說明服務(wù)器發(fā)來的證書是不可信任的。
（4）如果找到，那么瀏覽器就會從操作系統(tǒng)中取出頒發(fā)者CA 的公鑰(多數(shù)瀏覽器開發(fā)商發(fā)布
版本時，會事先在內(nèi)部植入常用認(rèn)證機關(guān)的公開密鑰)，然后對服務(wù)器發(fā)來的證書里面的簽名進行解密
（5）瀏覽器使用相同的hash算法計算出服務(wù)器發(fā)來的證書的hash值，將這個計算的hash值與證書中簽名做對比
（6）對比結(jié)果一致，則證明服務(wù)器發(fā)來的證書合法，沒有被冒充
（7）此時瀏覽器就可以讀取證書中的公鑰，用于后續(xù)加密了
5、傳送加密信息
這部分傳送的是用證書加密后的隨機值(私鑰)，目的就是讓服務(wù)端得到這個隨機值，以后客戶端和服務(wù)端的通信就可以通過這個隨機值來進行加密解密了。
6、服務(wù)端解密信息
服務(wù)端用私鑰解密后，得到了客戶端傳過來的隨機值(私鑰)，然后把內(nèi)容通過該值進行對稱加密
7、傳輸加密后的信息
這部分信息是服務(wù)端用私鑰加密后的信息，可以在客戶端被還原。
8、客戶端解密信息
客戶端用之前生成的私鑰解密服務(wù)端傳過來的信息，于是獲取了解密后的內(nèi)容，整個過程第三方即使監(jiān)聽到了數(shù)據(jù)，也束手無策。
原理如下圖

總結(jié)HTTP和HTTPS區(qū)別如下

1. https協(xié)議需要到ca申請證書，一般免費證書較少，因而需要一定費用。
2. http是超文本傳輸協(xié)議，信息是明文傳輸，https則是具有安全性的ssl加密傳輸協(xié)議。
3. http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。
4. http的連接很簡單，是無狀態(tài)的；HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，比http協(xié)議安全。

如何配置https

配置https最重要的是配置ssl證書，配置SSL證書可以參考SSL證書部署指南
這里我們以自簽證書來演示

生成自簽證書

生成私鑰文件
sudo openssl genrsa -out server.key 2048
生成自簽證書文件
sudo openssl req -new -x509 -days 1826 -key server.key -out server.crt

修改apache配置

apache2.4
需開啟的模塊
LoadModule ssl_module libexec/apache2/mod_ssl.so
LoadModule socache_shmcb_module libexec/apache2/mod_socache_shmcb.so

sudo vim httpd-ssl.conf

    DocumentRoot "/var/www/html"
    ServerName www.domain.com:443
    SSLEngine on
    SSLCertificateFile /usr/local/apache/conf/server.crt #添加證書文件
    SSLCertificateKeyFile /usr/local/apache/conf/server.key #添加私鑰文件

檢測配置文件是否有錯誤
sudo apachectl configtest
重啟apache
sudo apachectl restart

Fiddler/Charles是如何監(jiān)聽HTTPS?

第一步，F(xiàn)iddler截獲客戶端發(fā)送給服務(wù)器的HTTPS請求，F(xiàn)iddler偽裝成客戶端向服務(wù)器發(fā)送請求進行握手 。
第二步，服務(wù)器發(fā)回相應(yīng)，F(xiàn)iddler獲取到服務(wù)器的CA證書， 用根證書（這里的根證書是CA認(rèn)證中心給自己頒發(fā)的證書）公鑰進行解密， 驗證服務(wù)器數(shù)據(jù)簽名， 獲取到服務(wù)器CA證書公鑰。然后Fiddler偽造自己的CA證書（這里的CA證書，也是根證書，只不過是Fiddler偽造的根證書）， 冒充服務(wù)器證書傳遞給客戶端瀏覽器。
第三步，與普通過程中客戶端的操作相同，客戶端根據(jù)返回的數(shù)據(jù)進行證書校驗、生成密碼Pre_master、用Fiddler偽造的證書公鑰加密，并生成HTTPS通信用的對稱密鑰enc_key。
第四步，客戶端將重要信息傳遞給服務(wù)器， 又被Fiddler截獲。Fiddler將截獲的密文用自己偽造證書的私鑰解開， 獲得并計算得到HTTPS通信用的對稱密鑰enc_key。Fiddler將對稱密鑰用服務(wù)器證書公鑰加密傳遞給服務(wù)器。
第五步，與普通過程中服務(wù)器端的操作相同，服務(wù)器用私鑰解開后建立信任，然后再發(fā)送加密的握手消息給客戶端。
第六步，F(xiàn)iddler截獲服務(wù)器發(fā)送的密文， 用對稱密鑰解開， 再用自己偽造證書的私鑰加密傳給客戶端。
第七步，客戶端拿到加密信息后，用公鑰解開，驗證HASH。握手過程正式完成，客戶端與服務(wù)器端就這樣建立了”信任“。

在之后的正常加密通信過程中，F(xiàn)iddler如何在服務(wù)器與客戶端之間充當(dāng)?shù)谌吣兀?br /> 服務(wù)器—>客戶端：Fiddler接收到服務(wù)器發(fā)送的密文， 用對稱密鑰解開， 獲得服務(wù)器發(fā)送的明文。再次加密， 發(fā)送給客戶端。
客戶端—>服務(wù)端：客戶端用對稱密鑰加密，被Fiddler截獲后，解密獲得明文。再次加密，發(fā)送給服務(wù)器端。由于Fiddler一直擁有通信用對稱密鑰enc_key， 所以在整個HTTPS通信過程中信息對其透明。

參考文章

• HTTP,SSL/TLS和HTTPS協(xié)議的區(qū)別與聯(lián)系
• SSL證書部署指南
• 圖解SSL/TLS協(xié)議