幾幅圖，拿下 HTTPS

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

那么，接下來針對每一個(gè) TLS 握手做進(jìn)一步的介紹。

TLS 第一次握手

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

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

TLS 第二次握手

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

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

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

這個(gè)密碼套件看起來真讓人頭暈，好一大串，但是其實(shí)它是有固定格式和規(guī)范的?；镜男问绞恰?strong>密鑰交換算法 + 簽名算法 + 對稱加密算法 + 摘要算法」， 一般 WITH 單詞前面有兩個(gè)單詞，第一個(gè)單詞是約定密鑰交換的算法，第二個(gè)單詞是約定證書的驗(yàn)證算法。比如剛才的密碼套件的意思就是：

• 由于 WITH 單詞只有一個(gè) RSA，則說明握手時(shí)密鑰交換算法和簽名算法都是使用 RSA；

• 握手后的通信使用 AES 對稱算法，密鑰長度 128 位，分組模式是 GCM；

• 摘要算法 SHA384 用于消息認(rèn)證和產(chǎn)生隨機(jī)數(shù)；

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

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

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

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

客戶端驗(yàn)證證書

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

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

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

• 公鑰；

• 持有者信息；

• 證書認(rèn)證機(jī)構(gòu)（CA）的信息；

• CA 對這份文件的數(shù)字簽名及使用的算法；

• 證書有效期；

• 還有一些其他額外信息；

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

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

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

之所以要簽名，是因?yàn)楹灻淖饔每梢员苊庵虚g人在獲取證書時(shí)對證書內(nèi)容的篡改。

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

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

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

• 首先 CA 會(huì)把持有者的公鑰、用途、頒發(fā)者、有效時(shí)間等信息打成一個(gè)包，然后對這些信息進(jìn)行 Hash 計(jì)算，得到一個(gè) Hash 值；

• 然后 CA 會(huì)使用自己的私鑰將該 Hash 值加密，生成 Certificate Signature，也就是 CA 對證書做了簽名；

• 最后將 Certificate Signature 添加在文件證書上，形成數(shù)字證書；

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

• 首先客戶端會(huì)使用同樣的 Hash 算法獲取該證書的 Hash 值 H1；

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

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

證書鏈

但事實(shí)上，證書的驗(yàn)證過程中還存在一個(gè)證書信任鏈的問題，因?yàn)槲覀兿?CA 申請的證書一般不是根證書簽發(fā)的，而是由中間證書簽發(fā)的，比如百度的證書，從下圖你可以看到，證書的層級有三級：

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

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

• “GlobalSign Organization Validation CA - SHA256 - G2” 證書被信任后，可以使用 “GlobalSign Organization Validation CA - SHA256 - G2” 證書中的公鑰去驗(yàn)證 baidu.com 證書的可信性，如果驗(yàn)證通過，就可以信任 baidu.com 證書。

在這四個(gè)步驟中，最開始客戶端只信任根證書 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àn)g覽器的軟件商，所以由軟件商預(yù)載了根證書的 GlobalSign 都可被信任。

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

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

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

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

TLS 第三次握手

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

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

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

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

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

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

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

TLS 第四次握手

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

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

RSA 算法的缺陷

使用 RSA 密鑰協(xié)商算法的最大問題是不支持前向保密。因?yàn)榭蛻舳藗鬟f隨機(jī)數(shù)（用于生成對稱加密密鑰的條件之一）給服務(wù)端時(shí)使用的是公鑰加密的，服務(wù)端收到到后，會(huì)用私鑰解密得到隨機(jī)數(shù)。所以一旦服務(wù)端的私鑰泄漏了，過去被第三方截獲的所有 TLS 通訊密文都會(huì)被破解。

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

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

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

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

免責(zé)聲明：本文內(nèi)容由21ic獲得授權(quán)后發(fā)布，版權(quán)歸原作者所有，本平臺(tái)僅提供信息存儲(chǔ)服務(wù)。文章僅代表作者個(gè)人觀點(diǎn)，不代表本平臺(tái)立場，如有問題，請聯(lián)系我們，謝謝！