提綱

TLS握手過程

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

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

所以安全上存在以下三個?險：

? ? 1.竊聽?險，?如通信鏈路上可以獲取通信內(nèi)容，?戶號容易沒。

? ? 2.篡改?險，?如強制植?垃圾?告，視覺污染，?戶眼容易瞎。

? ? 3.冒充?險，?如冒充淘寶?站，?戶錢容易沒。

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

HTTPS與HTTP對比

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

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

? ? 2.校驗機制：校驗信息傳輸過程中是否有被第三?篡改過，如果被篡改過，則會有警告提示；

? ? 3.身份證書：證明淘寶是真的淘寶?；

可?，有了?TLS?協(xié)議，能保證?HTTP?通信是安全的了，那么在進(jìn)??HTTP?通信前，需要先進(jìn)??TLS?握?。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)歷來四次握?：

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ù)字證書。

數(shù)字證書

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

Serve Hello Done

TLS?第三次握?

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

Client?Key Exchage

服務(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ā)送消息

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

摘要

可以發(fā)現(xiàn)，「Change Cipher Spec」之前傳輸?shù)?TLS?握?數(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é)商算法，這?簡單介紹它的?作流程。

DH密鑰交換

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

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