解析HTTPS

本文主要是對HTTPS作一個總結，主要講解HTTPS的實質、HTTPS加密原理、HTTPS的通訊過程等。

HTTPS是什麼

HTTP存在問題

因爲HTTP協議過於簡單：

• 通訊使用明文（不加密），內容可能會被竊聽。
• 不驗證通訊方的身份，所以可能遭遇假裝
• 沒法驗證報文的完整性，因此有可能已遭篡改。

爲了解決諸多問題，HTTPS應運而生。

HTTPS的實質

HTTP加上加密處理、認證機制、以及完整性保護後的就是HTTPS。

須要知道的是，HTTPS並不是是應用層的一種新的協議。只是HTTP通訊接口部分用SSL或TLS協議代替而已。也就是說，所謂的HTTPS，其實就是身披SSL協議外殼的HTTP。

值得一提的是，SSL是獨立於HTTP協議的，也就是說其餘運行在應用層的協議都可配合SSL協議使用。現今SSL是最爲普遍的網絡安全技術。

SSL和TLS

HTTPS中使用了SSL和TLS這兩個協議。

TLS以SSL3.0爲基準，後又制定了TLS1.0、TLS1.1和TLS1.2。當前主流的版本是SSL3.0和TLS1.0。

TLS是以SSL爲原型開發的協議，有時候會統稱該協議爲SSL。

HTTPS的加密原理

近代的加密算法中加密算法是公開的，而密鑰是保密的。經過這種方式來保持加密方法的安全性。

加密和解密要用到密鑰，若是沒有密鑰就沒有辦法對密碼解密。換句話來講，任何人只要持有密鑰就可以對密文進行解密。

HTTPS在加密過程當中使用了非對稱加密技術和對稱加密技術。

對稱加密算法

採用單鑰密碼系統的加密方式，同一個密鑰能夠同時作信息的加密和解密，這種加密的方法稱爲對稱加密，也稱爲單密鑰加密。

下面會把對稱加密算法稱爲共享密鑰加密算法。

假如如今，SSL在通訊過程當中，使用了對稱加密算法，也就是說客戶端和服務器同時共享一個密鑰。

因而，以共享密鑰的方式加密，必須將密鑰發給對方。這個時候，假如通訊過程被監聽，密鑰被攻擊者獲取了，那麼這個時候也就失去了加密的意義了。

那麼，有沒有辦法解決這個問題呢？答案是確定的，也就是使用兩把密鑰。

下面先看使用兩把密鑰的非對稱加密算法。

非對稱加密算法

與對稱加密算法相反，非對稱加密算法須要兩個密鑰來進行加密和解密，這兩個密鑰是配對的，分別是公開密鑰（公鑰）和私有密鑰（私鑰）。

通常狀況下，公鑰是能夠被公開的，它主要用來加密明文。而相應的，私鑰不能被公開，用來解密公鑰加密的密文。

值得注意的是：公鑰加密後的密文只能經過對應的私鑰來解密，而私鑰加密的密文卻能夠經過對應的公鑰來解密。

以上，公鑰加密私鑰解密用來加密，私鑰加密公鑰解密用來簽名。相關用途後面會講到。

下面會把非對稱加密算法稱爲公開密鑰加密算法。

因而如今，假設如今由服務器來生成一對公鑰和私鑰。

當客戶端第一次發請求和服務器協商的時候，服務器就生成了一對公鑰和私鑰。

緊接着，服務器把公鑰發給客戶端（明文，不須要作任何加密），客戶端接收後，隨機生成一個密鑰，使用服務器發過來的公鑰進行加密。

再接着，客戶端把使用公鑰加密的密鑰發給服務器，服務器接收到了之後，用配對的私鑰進行解密，就獲得了客戶端隨機生成的那個密鑰。

這個時候，客戶端和服務端所持的密鑰都是相同的。此時，交換密鑰環節就完成了。

因而通訊開始時就可進行上面所述的共享密鑰加密方式來進行加密。

同時使用

可能，有小夥伴就會問，爲何要大費周章使用非對稱加密的方式，而後再獲得相同的密鑰，進行共享密鑰加密的通訊呢？

因爲公開密鑰加密處理起來比共享密鑰加密方式更爲複雜，所以在通訊的時候使用公開密鑰加密的方式，效率很低。

因而，咱們須要使用非對稱加密的方式來保證密鑰共享的過程當中密鑰的安全性，然後在通訊的過程當中使用對稱加密算法，這是最合理的設計方式，在保證安全性的同時又保證了性能。

因此，HTTPS採用共享密鑰加密和公開密鑰加密二者並用的混合加密機制。在交換密鑰使用環節使用公開密鑰加密方式，以後創建的通訊交換報文階段則使用共享密鑰加密方式。

以上，大概就是使用對稱加密和非對稱加密的過程。看似過程很完美，其實還存在着一個問題，就是：如何保證服務器傳過來的公開密鑰的正確性。換句話說，就是保證它不被攔截篡改。

使用證書保證公鑰的正確性

假如如今正準備和某臺服務器創建公開密鑰加密方式下的通訊，如何證實客戶端收到的公開密鑰就是本來預想的那臺服務器發行的公開密鑰呢？或許，在公開密鑰傳輸的過程當中，真正的公開密鑰可能已經被攻擊者替換掉了。

爲了解決這個問題，可使用由數字證書機構和其相關頒發的公開密鑰證書。

下面闡述一下數字證書認證機構（簡稱CA）的業務流程：

首先，服務器的運營人員向數字證書機構提出公開密鑰的申請。數字證書認證機構在判明提出申請者的身份以後，會對已申請的公開密鑰作數字簽名，而後分配這個已簽名的公開密鑰，並將該公開密鑰放入公鑰證書後綁定在一塊兒。
咱們用白話文來翻譯一下上面這段話：

• 首先，CA會向申請者頒發一個證書，這個證書裏面的內容有：簽發者、證書用途、使用的HASH算法、簽名所使用的算法、證書到期的時間等等。
• 緊接着，把上面所提到的內容，作一次HASH求值，獲得一個HASH值。
• 再接着，用CA的私鑰對這個HASH值和所使用的HASH算法加密，這樣就完成了數字簽名。而用CA的私鑰加密後，就生成了相似人體指紋的簽名，任何篡改證書的嘗試，都會被數字簽名發現。
• 最後，把數字簽名，附在數字證書的末尾，傳輸給服務器。

接下來，服務器會把這份由數字證書認證機構頒發的公鑰證書發給客戶端。這個時候，客戶端可使用數字證書機構的公開密鑰對其進行驗證。一旦驗證成功，客戶端便可以肯定這個公開密鑰是可信的。
咱們再用白話文來翻譯一下：

• 客戶端拿到這個數字證書之後，用CA私鑰對應的公鑰，能夠解密數字證書末尾的數字簽名，獲得HASH值和所採用的HASH算法。
• 緊接着，客戶端按照解密到的這個HASH算法，對證書的內容求HASH值。若是經過CA公鑰解密的HASH和經過計算求得的HASH值相同，那麼認證經過，不然失敗。
• 若是認證經過，就能夠取得服務器的公開密鑰。

那客戶端上面的CA公鑰是從哪裏來的呢？

其實，CA除了給申請者發佈證書，它本身自己也有本身的證書。CA自身的數字證書（通常由它本身生成）在咱們操做系統剛安裝好的時候，這些CA自身的數字證書就已經被微軟（或者其它操做系統的開發機構）安裝在操做系統中了。而CA的公鑰就包含在其中。這樣，CA就能夠經過自身的私鑰對發佈的數字證書進行簽名，而在客戶端就可以用對應的公鑰來對其進行解密。

其具體過程是這樣子的（圖中簡化了數字簽名的過程）：

這裏其實就用到了非對稱加密算法，只不過如今這個加密算法用來簽名而不是加密。

使用私鑰加密，公鑰解密，用於公鑰的持有者驗證經過私鑰加密的內容是否被篡改，可是不用來保證內容是否被他人得到。

而使用公鑰加密，私鑰解密，則是相反的，它不保證信息被他人截獲篡改，可是保證信息沒法被中間人得到。

客戶端證書

HTTPS中不只可使用服務器證書，還可使用客戶端證書。以客戶端證書進行客戶端認證，它的做用與服務器證書是相同的。

因爲客戶端獲取證書須要用戶自行安裝客戶端證書，同時也面臨着費用的問題。

所以，現狀是，安全性極高的認證機構可辦法客戶端證書可是僅用於特殊用途的業務。好比那些可支撐客戶端證書支出費用的業務。

例如，銀行的網上銀行就採用了客戶端證書。在登陸網銀時不只要求用戶確認輸入ID和密碼，還會要求用戶的客戶端證書，以確認用戶是否從特定的終端訪問網銀。

HTTPS通訊的過程

如今咱們來理清一下SSL創建的過程：

1. 客戶端經過發送Client Hello報文開始SSL通訊。報文中包含客戶端支持的SSL的指定版本、加密組件（Cipher Suite）列表（所使用的加密算法及密鑰長度等）。
   注意：客戶端還會附加一個隨機數，這裏記爲A。
   
   
2. 服務器可進行SSL通訊時，會以Server Hello報文做爲應答。和客戶端同樣，在報文中包含SSL版本以及加密組件。服務器的加密組件內容是從接收到的客戶端加密組件內篩選出來的。
   注意：這裏服務器一樣會附加一個隨機數，發給客戶端，這裏記爲B。
   
   
3. 以後服務器發送Certificate報文。報文中包含公開密鑰證書。（具體的數字簽名請看證書一節）
   
   
4. 最後服務器發送Server Hello Done報文通知客戶端，最初階段的SSL握手協商部分結束。
   
   
5. SSL第一次握手結束後，客戶端會對服務器發過來的證書進行驗證，若是驗證成功，解密取出證書中的公鑰。（具體查看證書一節）
   接着，客戶端以Client Key Exchange報文做爲迴應。報文中包含通訊加密中使用的一種被稱爲Pre-master secret的隨機密碼串。該報文使用從證書中解密得到的公鑰進行加密（其實就是服務器的公鑰）。
   
   
6. 客戶端繼續發送Change Cipher Spec報文。用於告知服務端，客戶端已經切換到以前協商好的加密套件（Cipher Suite）的狀態，準備使用以前協商好的加密套件加密數據並傳輸了。
   
   
7. 客戶端發送Finished報文。該報文包含鏈接至今所有報文的總體校驗值（也就是HASH值），用來供服務器校驗。
   
   
8. 服務器接收到客戶端的請求以後，使用私鑰解密報文，把Pre-master secret取出來。接着，服務器一樣發送Change Cipher Spec報文。
   
   
9. 服務器一樣發送Finished報文，用來供客戶端校驗。
   
   
10. 服務器和客戶端的Finished報文交換完畢以後，SSL鏈接就算創建完成。固然，通訊會受到SSL的保護。今後處開始進行應用層協議的通訊，即發送HTTP請求。
    
    
11. 應用層協議通訊，即發送HTTP響應。
    
    
12. 最後由客戶端斷開鏈接。斷開鏈接時，發送close_notify報文。上圖作了一些省略，這步以後再發送TCP FIN報文來關閉與TCP的通訊。

讀到這裏，你可能會對上面的一些細節產生不少疑惑，如今咱們一個個來理清楚？

問題一

爲何最後客戶端和服務端都要發送一個Finish報文？

上面已經說起，Finish報文是對至今所有報文的總體校驗值（也就是HASH值）。當客戶端把這個值經過獲得的公鑰進行加密的時候，服務器獲得以後對其進行解密，而後再對所有報文進行一個HASH求值。若是這個值跟解密獲得的值相等的話，那麼說明客戶端是可信賴的。
一樣的，服務器發送這樣的一個總體校驗值，用來客戶端驗證服務器是不是真正要進行通訊的那一個。
綜上，這個Finish報文就是用來校驗雙方的身份的。

問題二

整個過程當中產生的三個隨機數有什麼用呢？還有，後面進行HTTP通訊的時候，是用哪個密鑰進行加密，還有怎麼保證報文的完整性。

看下面這張圖。

對於客戶端：
當其生成了Pre-master secret以後，會結合原來的A、B隨機數，用DH算法計算出一個master secret，緊接着根據這個master secret推導出hash secret和session secret。

對於服務端：
當其解密得到了Pre-master secret以後，會結合原來的A、B隨機數，用DH算法計算出一個master secret，緊接着根據這個master secret推導出hash secret和session secret。

在客戶端和服務端的 master secret是依據三個隨機數推導出來的，它是不會在網絡上傳輸的，只有雙方知道，不會有第三者知道。同時，客戶端推導出來的 session secret和 hash secret與服務端也是徹底同樣的。

那麼如今雙方若是開始使用對稱算法加密來進行通信，使用哪一個做爲共享的密鑰呢？過程是這樣子的：

雙方使用對稱加密算法進行加密，用hash secret對HTTP報文作一次運算生成一個MAC，附在HTTP報文的後面，而後用session-secret加密全部數據（HTTP+MAC），而後發送。

接收方則先用session-secret解密數據，而後獲得HTTP+MAC，再用相同的算法計算出本身的MAC，若是兩個MAC相等，證實數據沒有被篡改。

MAC(Message Authentication Code)稱爲報文摘要，可以查知報文是否遭到篡改，從而保護報文的完整性。

問題三

爲何要使用三個隨機數呢？

網友dog250是這麼解釋的：

"無論是客戶端仍是服務器，都須要隨機數，這樣生成的密鑰纔不會每次都同樣。因爲SSL協議中證書是靜態的，所以十分有必要引入一種隨機因素來保證協商出來的密鑰的隨機性。
對於RSA密鑰交換算法來講， pre-master secret自己就是一個隨機數，再加上hello消息中的隨機，三個隨機數經過一個密鑰導出器最終導出一個對稱密鑰。
pre-master secret的存在在於SSL協議不信任每一個主機都能產生徹底隨機的隨機數，若是隨機數不隨機，那麼 pre-master secret就有可能被猜出來，那麼僅適用 pre-master secret做爲密鑰就不合適了，所以必須引入新的隨機因素，那麼客戶端和服務器加上 pre-master secret三個隨機數一同生成的密鑰就不容易被猜出了，一個僞隨機可能徹底不隨機，但是是三個僞隨機就十分接近隨機了，每增長一個自由度，隨機性增長的可不是一。"

注：咱們在計算機所使用的隨機數都是僞隨機，而不是物理上所說的真正隨機。

另外，黑客可能攔截了這樣的一個加密的報文，他不對報文進行修改，而是不停的向報文的接受者發送重複的報文，以擾亂通訊的創建。因而，就能夠加這麼一個隨機數。只要任何一個通訊方，接收到的報文中的隨機數出現重複的狀況，就能夠知道有中間者對通訊的過程進行了擾亂，能夠當即中斷通訊。

問題四

若是黑客攔截了服務器把證書發送給客戶端，並對證書進行惡意修改，會出現什麼狀況？

第一種狀況，假如黑客只是單純的修改數字證書中的內容，那麼因爲數字簽名的存在，客戶端會很容易的判斷出報文是否被篡改。

第二種狀況，黑客不只修改了數字證書的內容，而且把數字簽名替換掉了，因爲黑客不可能知道CA的私鑰，因而在客戶端用CA的公鑰進行解密的時候，解密以後得不到正確的信息，也很容易判斷出報文是否被修改。

第三種狀況，黑客惡意的從相同的第三方CA申請了一個數字證書。因爲這個CA是真實存在的，因此客戶端是能夠用CA的公鑰進行解密，獲得了黑客提供的數字證書中的公鑰。可是，因爲數字證書在申請的時候，會綁定一個域名，當客戶端好比說瀏覽器，檢測到這個數字證書中的域名和咱們如今網頁訪問的域名不一致，便會發出警告，此時咱們也能得知數字證書被替換了。發出的警告以下：

必定要用HTTPS嗎

當HTTP披上SSL外殼以後，因爲加入了諸多驗證的機制，雖然安全性大大提升了，可是它的處理速度會變慢。慢的緣由分如下兩種：

• 服務器在與客戶端協商次數增多，也就是說總體上處理通訊量會不可避免的增長。
• SSL進行加密處理，在服務端和客戶端都須要進行加密和解密的運算處理。結果會消耗更多的硬件資源，致使負載增長。

可見，使用HTTPS會消耗更多的資源。若是每次通訊都加密，那麼平攤到一臺計算機上，可以處理的請求數量也一定會減小。

同時，使用HTTPS須要向CA購買證書，因而開銷也成爲考慮是否使用HTTPS的緣由之一。

因此，大部分的Web網站都採起了一個折中的方法。對於一些須要隱藏、私密的信息進行加密，而普通的信息不進行加密處理，以節省資源。

fiddler攔截HTTPS請求的原理

不少時候咱們能夠經過fiddler來進行抓HTTP包，可是當遇到鏈接採用的是HTTPS的時候，過程可能就不那麼愉快了。但實際上實現攔截也十分簡單。

fiddler攔截HTTPS請求最核心的地方在於真正的客戶端須要安裝fiddler的證書。這樣子的話，fiddler可以僞造出CA證書，達到欺騙客戶端，拿到須要的信息並推算出以後雙方正常通訊的對稱加密密鑰。

最後

這學期恰好有《信息安全》這門課程，那就簡明的介紹一下公鑰密碼密碼體系RSA算法原理是什麼。

它是這樣子工做的：

1. 選取兩個大素數p和q，相乘獲得n。
2. p-1和q-1相乘，獲得f(n)。
3. 隨機選取一個e與f(n)互質，而後獲得公鑰(e, n)。
4. 私鑰的求法爲ed = 1 mod f(n)。 [這是一個等價關係而不是一個表達式！也就是ed模fn(n)的結果是1，這是求模運算的逆運算，能夠用歐幾里德展轉相除法求得]
5. 最後獲得的私鑰爲(d, n)。

整個RSA公鑰密碼算法的難度其實在於分解這一個大數 n， pq=n正向運算很容易，逆向運算很困難，隨着這個數愈來愈大，想要逆向分解須要不少年的時間。

---

參考書籍：《圖解HTTP》
參考連接：
https://www.zhihu.com/questio...
http://www.cnblogs.com/Jeffre...