提綱

TLS握手過(guò)程

HTTP?由于是明?傳輸，所謂的明?，就是說(shuō)客戶端與服務(wù)端通信的信息都是?眼可?的，隨意使??個(gè)抓包?具

都可以截獲通信的內(nèi)容。

所以安全上存在以下三個(gè)?險(xiǎn)：

? ? 1.竊聽(tīng)?險(xiǎn)，?如通信鏈路上可以獲取通信內(nèi)容，?戶號(hào)容易沒(méi)。

? ? 2.篡改?險(xiǎn)，?如強(qiáng)制植?垃圾?告，視覺(jué)污染，?戶眼容易瞎。

? ? 3.冒充?險(xiǎn)，?如冒充淘寶?站，?戶錢(qián)容易沒(méi)。

HTTPS?在?HTTP?與?TCP?層之間加?了?TLS?協(xié)議，來(lái)解決上述的?險(xiǎn)。

HTTPS與HTTP對(duì)比

TLS?協(xié)議是如何解決?HTTP?的?險(xiǎn)的呢？

? ? 1.信息加密：?HTTP?交互信息是被加密的，第三?就?法被竊取；

? ? 2.校驗(yàn)機(jī)制：校驗(yàn)信息傳輸過(guò)程中是否有被第三?篡改過(guò)，如果被篡改過(guò)，則會(huì)有警告提示；

? ? 3.身份證書(shū)：證明淘寶是真的淘寶?；

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

TLS握手過(guò)程

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

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

事實(shí)上，不同的密鑰交換算法，TLS?的握?過(guò)程可能會(huì)有?些區(qū)別。這?先簡(jiǎn)單介紹下密鑰交換算法，因?yàn)榭紤]到性能的問(wèn)題，所以雙?在加密應(yīng)?信息時(shí)使?的是對(duì)稱加密密鑰，?對(duì)稱加密密鑰是不能被泄漏的，為了保證對(duì)稱加密密鑰的安全性，所以使??對(duì)稱加密的?式來(lái)保護(hù)對(duì)稱加密密鑰的協(xié)商，這個(gè)?作就是密鑰交換算法負(fù)責(zé)的。接下來(lái)，我們就以最簡(jiǎn)單的?RSA?密鑰交換算法，來(lái)看看它的?TLS?握?過(guò)程。

RSA?握?過(guò)程

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

在?RSA?密鑰協(xié)商算法中，客戶端會(huì)?成隨機(jī)密鑰，并使?服務(wù)端的公鑰加密后再傳給服務(wù)端。根據(jù)?對(duì)稱加密算

法，公鑰加密的消息僅能通過(guò)私鑰解密，這樣服務(wù)端解密后，雙?就得到了相同的密鑰，再?它加密應(yīng)?消息。

我??Wireshark??具抓了??RSA?密鑰交換的?TLS?握?過(guò)程，你可以從下?看到，?共經(jīng)歷來(lái)四次握?：

TLS握手

TLS?第?次握?

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

第一次握手

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

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è)密碼套件看起來(lái)真讓?頭暈，好??串，但是其實(shí)它是有固定格式和規(guī)范的。基本的形式是「密鑰交換算法?+簽名算法?+?對(duì)稱加密算法?+?摘要算法」， ?般?WITH?單詞前?有兩個(gè)單詞，第?個(gè)單詞是約定密鑰交換的算法，第?個(gè)單詞是約定證書(shū)的驗(yàn)證算法。?如剛才的密碼套件的意思就是：由于?WITH?單詞只有?個(gè)?RSA，則說(shuō)明握?時(shí)密鑰交換算法和簽名算法都是使??RSA；握?后的通信使??AES?對(duì)稱算法，密鑰?度?128?位，分組模式是?GCM；摘要算法?SHA384??于消息認(rèn)證和產(chǎn)?隨機(jī)數(shù)；

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

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

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

數(shù)字證書(shū)

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

Serve Hello Done

TLS?第三次握?

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

Client?Key Exchage

服務(wù)端收到后，??RSA?私鑰解密，得到客戶端發(fā)來(lái)的隨機(jī)數(shù)?(pre-master)。?此，客戶端和服務(wù)端雙?都共享了三個(gè)隨機(jī)數(shù)，分別是?Client Random、Server Random、pre-master。

于是，雙?根據(jù)已經(jīng)得到的三個(gè)隨機(jī)數(shù)，?成會(huì)話密鑰（Master Secret），它是對(duì)稱密鑰，?于對(duì)后續(xù)的?HTTP請(qǐng)求/響應(yīng)的數(shù)據(jù)加解密。?成完會(huì)話密鑰后，然后客戶端發(fā)?個(gè)「Change Cipher Spec」，告訴服務(wù)端開(kāi)始使?加密?式發(fā)送消息。

通知使用加密方式發(fā)送消息

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

摘要

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

TLS?第四次握?

服務(wù)器也是同樣的操作，發(fā)「Change Cipher Spec」和「Encrypted Handshake Message」消息，如果雙?都驗(yàn)證加密和解密沒(méi)問(wèn)題，那么握?正式完成。最后，就?「會(huì)話密鑰」加解密?HTTP?請(qǐng)求和響應(yīng)了。

RSA?算法的缺陷

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

為了解決這?問(wèn)題，于是就有了?DH?密鑰協(xié)商算法，這?簡(jiǎn)單介紹它的?作流程。

DH密鑰交換

客戶端和服務(wù)端各?會(huì)?成隨機(jī)數(shù)，并以此作為私鑰，然后根據(jù)公開(kāi)的?DH?計(jì)算公示算出各?的公鑰，通過(guò)?TLS握?雙?交換各?的公鑰，這樣雙?都有??的私鑰和對(duì)?的公鑰，然后雙?根據(jù)各?持有的材料算出?個(gè)隨機(jī)數(shù)，這個(gè)隨機(jī)數(shù)的值雙?都是?樣的，這就可以作為后續(xù)對(duì)稱加密時(shí)使?的密鑰。DH?密鑰交換過(guò)程中，即使第三?截獲了?TLS?握?階段傳遞的公鑰，在不知道的私鑰的情況下，也是?法計(jì)算出密鑰的，?且每?次對(duì)稱加密密鑰都是實(shí)時(shí)?成的，實(shí)現(xiàn)前向保密。

但因?yàn)?DH?算法的計(jì)算效率問(wèn)題，后?出現(xiàn)了?ECDHE?密鑰協(xié)商算法，我們現(xiàn)在?多數(shù)?站使?的正是?ECDHE?密鑰協(xié)商算法