[[374308]]

本文轉(zhuǎn)載自微信公眾號「小林coding 」，作者小林coding。轉(zhuǎn)載本文請聯(lián)系小林coding公眾號。

我很早之前寫過一篇關(guān)于 HTTP 和 HTTPS 的文章，但對于 HTTPS 介紹還不夠詳細(xì)，只講了比較基礎(chǔ)的部分，所以這次我們再來深入一下 HTTPS，用實戰(zhàn)抓包的方式，帶大家再來窺探一次 HTTPS。

對于還不知道對稱加密和非對稱加密的同學(xué)，你先復(fù)習(xí)我以前的這篇文章「硬核!30 張圖解 HTTP 常見的面試題」，本篇文章默認(rèn)大家已經(jīng)具備了這些知識。

TLS 握手過程

HTTP 由于是明文傳輸，所謂的明文，就是說客戶端與服務(wù)端通信的信息都是肉眼可見的，隨意使用一個抓包工具都可以截獲通信的內(nèi)容。

所以安全上存在以下三個風(fēng)險：

• 竊聽風(fēng)險，比如通信鏈路上可以獲取通信內(nèi)容，用戶號容易沒。
• 篡改風(fēng)險，比如強制植入垃圾廣告，視覺污染，用戶眼容易瞎。
• 冒充風(fēng)險，比如冒充淘寶網(wǎng)站，用戶錢容易沒。

HTTPS 在 HTTP 與 TCP 層之間加入了 TLS 協(xié)議，來解決上述的風(fēng)險。

TLS 協(xié)議是如何解決 HTTP 的風(fēng)險的呢?

• 信息加密：HTTP 交互信息是被加密的，第三方就無法被竊取;
• 校驗機制：校驗信息傳輸過程中是否有被第三方篡改過，如果被篡改過，則會有警告提示;
• 身份證書：證明淘寶是真的淘寶網(wǎng);

可見，有了 TLS 協(xié)議，能保證 HTTP 通信是安全的了，那么在進行 HTTP 通信前，需要先進行 TLS 握手。TLS 的握手過程，如下圖：

上圖簡要概述來 TLS 的握手過程，其中每一個「框」都是一個記錄(record)，記錄是 TLS 收發(fā)數(shù)據(jù)的基本單位，類似于 TCP 里的 segment。多個記錄可以組合成一個 TCP 包發(fā)送，所以通常經(jīng)過「四個消息」就可以完成 TLS 握手，也就是需要 2個 RTT 的時延，然后就可以在安全的通信環(huán)境里發(fā)送 HTTP 報文，實現(xiàn) HTTPS 協(xié)議。

所以可以發(fā)現(xiàn)，HTTPS 是應(yīng)用層協(xié)議，需要先完成 TCP 連接建立，然后走 TLS 握手過程后，才能建立通信安全的連接。

事實上，不同的密鑰交換算法，TLS 的握手過程可能會有一些區(qū)別。

這里先簡單介紹下密鑰交換算法，因為考慮到性能的問題，所以雙方在加密應(yīng)用信息時使用的是對稱加密密鑰，而對稱加密密鑰是不能被泄漏的，為了保證對稱加密密鑰的安全性，所以使用非對稱加密的方式來保護對稱加密密鑰的協(xié)商，這個工作就是密鑰交換算法負(fù)責(zé)的。

接下來，我們就以最簡單的 RSA 密鑰交換算法，來看看它的 TLS 握手過程。

RSA 握手過程

傳統(tǒng)的 TLS 握手基本都是使用 RSA 算法來實現(xiàn)密鑰交換的，在將 TLS 證書部署服務(wù)端時，證書文件中包含一對公私鑰，其中公鑰會在 TLS 握手階段傳遞給客戶端，私鑰則一直留在服務(wù)端，一定要確保私鑰不能被竊取。

在 RSA 密鑰協(xié)商算法中，客戶端會生成隨機密鑰，并使用服務(wù)端的公鑰加密后再傳給服務(wù)端。根據(jù)非對稱加密算法，公鑰加密的消息僅能通過私鑰解密，這樣服務(wù)端解密后，雙方就得到了相同的密鑰，再用它加密應(yīng)用消息。

我用 Wireshark 工具抓了用 RSA 密鑰交換的 TLS 握手過程，你可以從下面看到，一共經(jīng)歷來四次握手：

對應(yīng) Wireshark 的抓包，我也畫了一幅圖，你可以從下圖很清晰地看到該過程：

那么，接下來針對每一個 TLS 握手做進一步的介紹。

TLS 第一次握手

客戶端首先會發(fā)一個「Client Hello」消息，字面意思我們也能理解到，這是跟服務(wù)器「打招呼」。

消息里面有客戶端使用的 TLS 版本號、支持的密碼套件列表，以及生成的隨機數(shù)(Client Random)，這個隨機數(shù)會被服務(wù)端保留，它是生成對稱加密密鑰的材料之一。

TLS 第二次握手

當(dāng)服務(wù)端收到客戶端的「Client Hello」消息后，會確認(rèn) TLS 版本號是否支持，和從密碼套件列表中選擇一個密碼套件，以及生成隨機數(shù)(Server Random)。

接著，返回「Server Hello」消息，消息里面有服務(wù)器確認(rèn)的 TLS 版本號，也給出了隨機數(shù)(Server Random)，然后從客戶端的密碼套件列表選擇了一個合適的密碼套件。

可以看到，服務(wù)端選擇的密碼套件是 “Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256”。

這個密碼套件看起來真讓人頭暈，好一大串，但是其實它是有固定格式和規(guī)范的。基本的形式是「密鑰交換算法 + 簽名算法 + 對稱加密算法 + 摘要算法」， 一般 WITH 單詞前面有兩個單詞，第一個單詞是約定密鑰交換的算法，第二個單詞是約定證書的驗證算法。比如剛才的密碼套件的意思就是：

• 由于 WITH 單詞只有一個 RSA，則說明握手時密鑰交換算法和簽名算法都是使用 RSA;
• 握手后的通信使用 AES 對稱算法，密鑰長度 128 位，分組模式是 GCM;
• 摘要算法 SHA384 用于消息認(rèn)證和產(chǎn)生隨機數(shù);

就前面這兩個客戶端和服務(wù)端相互「打招呼」的過程，客戶端和服務(wù)端就已確認(rèn)了 TLS 版本和使用的密碼套件，而且你可能發(fā)現(xiàn)客戶端和服務(wù)端都會各自生成一個隨機數(shù)，并且還會把隨機數(shù)傳遞給對方。

那這個隨機數(shù)有啥用呢?其實這兩個隨機數(shù)是后續(xù)作為生成「會話密鑰」的條件，所謂的會話密鑰就是數(shù)據(jù)傳輸時，所使用的對稱加密密鑰。

然后，服務(wù)端為了證明自己的身份，會發(fā)送「Server Certificate」給客戶端，這個消息里含有數(shù)字證書。

隨后，服務(wù)端發(fā)了「Server Hello Done」消息，目的是告訴客戶端，我已經(jīng)把該給你的東西都給你了，本次打招呼完畢。

客戶端驗證證書

在這里剎個車，客戶端拿到了服務(wù)端的數(shù)字證書后，要怎么校驗該數(shù)字證書是真實有效的呢?

數(shù)字證書和 CA 機構(gòu)

在說校驗數(shù)字證書是否可信的過程前，我們先來看看數(shù)字證書是什么，一個數(shù)字證書通常包含了：

• 公鑰;
• 持有者信息;
• 證書認(rèn)證機構(gòu)(CA)的信息;
• CA 對這份文件的數(shù)字簽名及使用的算法;
• 證書有效期;
• 還有一些其他額外信息;

那數(shù)字證書的作用，是用來認(rèn)證公鑰持有者的身份，以防止第三方進行冒充。說簡單些，證書就是用來告訴客戶端，該服務(wù)端是否是合法的，因為只有證書合法，才代表服務(wù)端身份是可信的。

我們用證書來認(rèn)證公鑰持有者的身份(服務(wù)端的身份)，那證書又是怎么來的?又該怎么認(rèn)證證書呢?

為了讓服務(wù)端的公鑰被大家信任，服務(wù)端的證書都是由 CA (Certificate Authority，證書認(rèn)證機構(gòu))簽名的，CA 就是網(wǎng)絡(luò)世界里的公安局、公證中心，具有極高的可信度，所以由它來給各個公鑰簽名，信任的一方簽發(fā)的證書，那必然證書也是被信任的。

之所以要簽名，是因為簽名的作用可以避免中間人在獲取證書時對證書內(nèi)容的篡改。

數(shù)字證書簽發(fā)和驗證流程

如下圖圖所示，為數(shù)字證書簽發(fā)和驗證流程：

CA 簽發(fā)證書的過程，如上圖左邊部分：

• 首先 CA 會把持有者的公鑰、用途、頒發(fā)者、有效時間等信息打成一個包，然后對這些信息進行 Hash 計算，得到一個 Hash 值;
• 然后 CA 會使用自己的私鑰將該 Hash 值加密，生成 Certificate Signature，也就是 CA 對證書做了簽名;
• 最后將 Certificate Signature 添加在文件證書上，形成數(shù)字證書;

客戶端校驗服務(wù)端的數(shù)字證書的過程，如上圖右邊部分：

首先客戶端會使用同樣的 Hash 算法獲取該證書的 Hash 值 H1;

通常瀏覽器和操作系統(tǒng)中集成了 CA 的公鑰信息，瀏覽器收到證書后可以使用 CA 的公鑰解密 Certificate Signature 內(nèi)容，得到一個 Hash 值 H2 ;

最后比較 H1 和 H2，如果值相同，則為可信賴的證書，否則則認(rèn)為證書不可信。

證書鏈

但事實上，證書的驗證過程中還存在一個證書信任鏈的問題，因為我們向 CA 申請的證書一般不是根證書簽發(fā)的，而是由中間證書簽發(fā)的，比如百度的證書，從下圖你可以看到，證書的層級有三級：

對于這種三級層級關(guān)系的證書的驗證過程如下：

• 客戶端收到 baidu.com 的證書后，發(fā)現(xiàn)這個證書的簽發(fā)者不是根證書，就無法根據(jù)本地已有的根證書中的公鑰去驗證 baidu.com 證書是否可信。于是，客戶端根據(jù) baidu.com 證書中的簽發(fā)者，找到該證書的頒發(fā)機構(gòu)是 “GlobalSign Organization Validation CA - SHA256 - G2”，然后向 CA 請求該中間證書。
• 請求到證書后發(fā)現(xiàn) “GlobalSign Organization Validation CA - SHA256 - G2” 證書是由 “GlobalSign Root CA” 簽發(fā)的，由于 “GlobalSign Root CA” 沒有再上級簽發(fā)機構(gòu)，說明它是根證書，也就是自簽證書。應(yīng)用軟件會檢查此證書有否已預(yù)載于根證書清單上，如果有，則可以利用根證書中的公鑰去驗證 “GlobalSign Organization Validation CA - SHA256 - G2” 證書，如果發(fā)現(xiàn)驗證通過，就認(rèn)為該中間證書是可信的。
• “GlobalSign Organization Validation CA - SHA256 - G2” 證書被信任后，可以使用 “GlobalSign Organization Validation CA - SHA256 - G2” 證書中的公鑰去驗證 baidu.com 證書的可信性，如果驗證通過，就可以信任 baidu.com 證書。

在這四個步驟中，最開始客戶端只信任根證書 GlobalSign Root CA 證書的，然后 “GlobalSign Root CA” 證書信任 “GlobalSign Organization Validation CA - SHA256 - G2” 證書，而 “GlobalSign Organization Validation CA - SHA256 - G2” 證書又信任 baidu.com 證書，于是客戶端也信任 baidu.com 證書。

總括來說，由于用戶信任 GlobalSign，所以由 GlobalSign 所擔(dān)保的 baidu.com 可以被信任，另外由于用戶信任操作系統(tǒng)或瀏覽器的軟件商，所以由軟件商預(yù)載了根證書的 GlobalSign 都可被信任。

操作系統(tǒng)里一般都會內(nèi)置一些根證書，比如我的 MAC 電腦里內(nèi)置的根證書有這么多：

這樣的一層層地驗證就構(gòu)成了一條信任鏈路，整個證書信任鏈驗證流程如下圖所示：

最后一個問題，為什么需要證書鏈這么麻煩的流程?Root CA 為什么不直接頒發(fā)證書，而是要搞那么多中間層級呢?

這是為了確保根證書的絕對安全性，將根證書隔離地越嚴(yán)格越好，不然根證書如果失守了，那么整個信任鏈都會有問題。

TLS 第三次握手

客戶端驗證完證書后，認(rèn)為可信則繼續(xù)往下走。接著，客戶端就會生成一個新的隨機數(shù) (pre-master)，用服務(wù)器的 RSA 公鑰加密該隨機數(shù)，通過「Change Cipher Key Exchange」消息傳給服務(wù)端。

服務(wù)端收到后，用 RSA 私鑰解密，得到客戶端發(fā)來的隨機數(shù) (pre-master)。

至此，客戶端和服務(wù)端雙方都共享了三個隨機數(shù)，分別是 Client Random、Server Random、pre-master。

于是，雙方根據(jù)已經(jīng)得到的三個隨機數(shù)，生成會話密鑰(Master Secret)，它是對稱密鑰，用于對后續(xù)的 HTTP 請求/響應(yīng)的數(shù)據(jù)加解密。

生成完會話密鑰后，然后客戶端發(fā)一個「Change Cipher Spec」，告訴服務(wù)端開始使用加密方式發(fā)送消息。

然后，客戶端再發(fā)一個「Encrypted Handshake Message(Finishd)」消息，把之前所有發(fā)送的數(shù)據(jù)做個摘要，再用會話密鑰(master secret)加密一下，讓服務(wù)器做個驗證，驗證加密通信是否可用和之前握手信息是否有被中途篡改過。

可以發(fā)現(xiàn)，「Change Cipher Spec」之前傳輸?shù)?TLS 握手?jǐn)?shù)據(jù)都是明文，之后都是對稱密鑰加密的密文。

TLS 第四次握手

服務(wù)器也是同樣的操作，發(fā)「Change Cipher Spec」和「Encrypted Handshake Message」消息，如果雙方都驗證加密和解密沒問題，那么握手正式完成。

最后，就用「會話密鑰」加解密 HTTP 請求和響應(yīng)了。

RSA 算法的缺陷

使用 RSA 密鑰協(xié)商算法的最大問題是不支持前向保密。因為客戶端傳遞隨機數(shù)(用于生成對稱加密密鑰的條件之一)給服務(wù)端時使用的是公鑰加密的，服務(wù)端收到到后，會用私鑰解密得到隨機數(shù)。所以一旦服務(wù)端的私鑰泄漏了，過去被第三方截獲的所有 TLS 通訊密文都會被破解。

為了解決這一問題，于是就有了 DH 密鑰協(xié)商算法，這里簡單介紹它的工作流程。

客戶端和服務(wù)端各自會生成隨機數(shù)，并以此作為私鑰，然后根據(jù)公開的 DH 計算公示算出各自的公鑰，通過 TLS 握手雙方交換各自的公鑰，這樣雙方都有自己的私鑰和對方的公鑰，然后雙方根據(jù)各自持有的材料算出一個隨機數(shù)，這個隨機數(shù)的值雙方都是一樣的，這就可以作為后續(xù)對稱加密時使用的密鑰。

DH 密鑰交換過程中，即使第三方截獲了 TLS 握手階段傳遞的公鑰，在不知道的私鑰的情況下，也是無法計算出密鑰的，而且每一次對稱加密密鑰都是實時生成的，實現(xiàn)前向保密。

但因為 DH 算法的計算效率問題，后面出現(xiàn)了 ECDHE 密鑰協(xié)商算法，我們現(xiàn)在大多數(shù)網(wǎng)站使用的正是 ECDHE 密鑰協(xié)商算法，關(guān)于 ECDHE 握手的過程，將在下一篇揭曉，盡情期待哦。

原文鏈接：https://mp.weixin.qq.com/s/U9SRLE7jZTB6lUZ6c8gTKg