一文讀懂HTTPS

前言

關於HTTPS的文章有不少，你們的文章講的那是真的詳細，功底我着實佩服。雖然已經有了這樣優秀的文章，但不影響我寫做的熱情，學習知識，分享是必不可少的一環。文章不是照搬，而是本身理解加工後純手打的。

學習前端開發果真仍是繞不開計算機網絡基礎，今天面試掛在了這裏，痛定思痛，讓咱們一塊兒來了解下HTTPS究竟是個什麼玩意。

靈魂拷問

你是否曾認爲，證書是用來加密的？😄

對稱加密

通訊雙方，使用同一個密鑰對信息加密和解密。只有知道密鑰的人才能獲取內容。

但通訊雙方必須約定好密鑰，且不能泄露密鑰。而實際上，只要使用網絡傳輸，就存在報文泄露的風險。況且HTTP協議本就是明文傳輸，雙方約定密鑰的過程，徹底是衆目睽睽之下。這種狀況下沒法保證你的密鑰沒有被第三方截獲。隔牆有耳一說，對吧？因此出現了非堆成加密

非對稱加密

通訊雙方每一個人都有兩把鑰匙，公鑰任何人均可以知道，私鑰只有本身知道。

且存在這樣一個特色：使用公鑰加密的內容，只有對應的私鑰才能解開，使用私鑰加密的內容，只有對應的公鑰才能夠解開。所謂，非對稱。

根據這樣的特色，A發消息給B，使用B的公鑰加密，B收到後使用本身的私鑰解密，就能夠獲取到內容了。

因此通訊時，雙方首先要互換公鑰。A和B通訊開始後，中間人徹底能夠在截獲A的公鑰後，替換成本身的公鑰發送給B，只要B使用該公鑰加密，中間人就可使用本身的私鑰解密，得到內容。雙方的通訊雖不至於衆目睽睽，卻也暴露給了中間人，總歸是不安全的。

你可能要問了，那B不用中間人的公鑰加密不就行了？

實際上B並不知道該公鑰是否是A的，A也一樣不肯定它收到的公鑰是否是來自B。

因此引出了一個問題。A如何判斷你加密使用的公鑰確實是B的，而不是中間人的？即，如何判斷公鑰身份是否有效？

數字證書：

聯繫實際，考慮到身份證實必需要第三方機構，咱們必須無條件信任它。本身是沒辦法證實本身的身份的。這個第三方機構通常是CA（Certificate Authority），頒發證書的具體過程以下：

B將本身的我的信息，和公鑰發送給CA機構（這裏會不會出現中間人攻擊？），CA機構使用哈希算法對發來的我的信息和公鑰進行計算，生成一個摘要，並使用CA本身的私鑰進行加密生成數字簽名。最後將數字簽名和原信息（B的公鑰和信息）合併，生成數字證書。

這裏用到了哈希算法，它的特色是，只要原信息變化，計算獲得的值就會發生巨大的變化。以此來確認內容是否遭到篡改

再借鑑一張圖：

因此，在通訊時，B先將本身的證書發送給A，A使用一樣的哈希算法，對證書內B的信息進行計算，生成一份摘要。同時對證書內的數字簽名進行解密，拿到事先加密的摘要，對比兩份摘要的內容是否一致，即可以肯定公鑰是否被篡改。

最根本的問題

1. 公鑰發送給CA機構的過程當中，不會被中間人攔截嗎？
2. 數字簽名是使用CA的私鑰加密的，解密須要使用CA的公鑰，咱們如何獲取？獲取公鑰的過程當中若是又被截獲了，豈不成了死循環？

根證書

如下內容摘自百度百科

根證書是CA認證中心給本身頒發的證書,是信任鏈的起始點。安裝根證書意味着對這個CA認證中心的信任。從技術上講，證書其實包含三部分，用戶的信息，用戶的公鑰，還有CA中心對該證書裏面的信息的簽名。驗證一份證書的真僞（即驗證CA中心對該證書信息的簽名是否有效），須要用CA 中心的公鑰驗證，而CA中心的公鑰存在於對這份證書進行簽名的證書內，故須要下載該證書，但使用該證書驗證又需先驗證該證書自己的真僞，故又要用簽發該證書的證書來驗證，這樣一來就構成一條證書鏈的關係，這條證書鏈在哪裏終結呢？答案就是根證書，根證書是一份特殊的證書，它的簽發者是它自己，下載根證書就代表您對該根證書如下所簽發的證書都表示信任，而技術上則是創建起一個驗證證書信息的鏈條，證書的驗證追溯至根證書即爲結束。因此說用戶在使用本身的數字證書以前必須先下載根證書。

通常來講，根證書是內置在操做系統/瀏覽器中的，隨操做系統的發佈而發佈。你信任操做系統，也就信任了這份證書。這就是證書鏈條的終點。

HTTPS

終於到了HTTPS。前面咱們提到了加密算法和證書。HTTPS是如何選擇的？

首先，安全起見，咱們應該使用非對稱加密算法。但實際上這種算法的效率並不夠高，能夠想象，存在兩次加密解密的過程。而對稱加密算法的效率就還算不錯。因而產生了這樣一種思路：

使用對稱加密算法來傳輸信息，但密鑰使用非對稱加密算法來傳輸。因此但願你們牢記：HTTPS中，非對稱加密算法，僅用來傳遞對稱加密算法的密鑰。

握手過程

HTTPS握手過程分爲四個階段：

1. 瀏覽器發起HTTPS請求，生一次個隨機數，附帶上支持的加密算法列表和協議版本號。
2. 服務器驗證協議版本號是否一致，一致則生成一個隨機數，隨證書一同發送回客戶端，不然拒絕請求。
3. 瀏覽器經過根證書驗證服務器證書是否有效，如有效則說明證書中的服務器公鑰有效。生成一個隨機數，再生成一個全部內容的哈希值（一共三個隨機數），並使用服務器公鑰加密後發送。若證書無效，則瀏覽器提示風險。
4. 服務器接收到以後，使用私鑰解密發來的內容，並對全部內容進行一樣的哈希值計算，再和收到的哈希值比對。若內容一致，則經過三個隨機數按照約定的加密算法生成會話密鑰（也就是對稱加密密鑰），並回應客戶端握手完成。

注意到，前兩次握手過程是明文傳輸的。接下來，客戶端與服務器進入加密通訊，就徹底是使用普通的HTTP協議，只不過用會話密鑰來加密內容

爲何須要三個隨機數？這三個隨機數又被稱爲pre-master key

引用d520的解釋：

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

斷開鏈接後如何恢復：

1. session ID：每一次會話都有一個編號，會話中斷後再次鏈接須要客戶端給出這個編號。服務器有這個記錄則不用從新鏈接。此種方式對分佈式集羣不太友好
2. session ticket：只有服務器能解密，裏面包含會話信息。是在上一次會話中發給用戶的。

參考

1. 【阮一峯】SSL/TLS協議運行機制的概述
2. 【碼農翻身公衆號】一個故事講完HTTPS