https握手與密鑰協(xié)商過程

1、https握手與密鑰協(xié)商過程https握手與密鑰協(xié)商過程基于 RSA 握手和密鑰交換的客戶端驗證服務(wù)器為示例詳解握手過程。1.client_hello客戶端發(fā)起請求，以明文傳輸請求信息，包含版本信息，加密套件候選列表，壓縮算法候選列表，隨機數(shù)，擴展字段等信息，相關(guān)信息如下：支持的最高TSL協(xié)議版本version，從低到高依次 SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2，當(dāng)前基本不再使用低于 TLSv1 的版本;客戶端支持的加密套件 cipher suites 列表， 每個加密套件對應(yīng)前面 TLS 原理中的四個功能的組合：認(rèn)證算法 Au (身份驗證)、密鑰交換算法 Key

2、Exchange(密鑰協(xié)商)、對稱加密算法 Enc (信息加密)和信息摘要 Mac(完整性校驗);支持的壓縮算法 compression methods 列表，用于后續(xù)的信息壓縮傳輸;隨機數(shù) random_C，用于后續(xù)的密鑰的生成;擴展字段 extensions，支持協(xié)議與算法的相關(guān)參數(shù)以及其它輔助信息等，常見的 SNI 就屬于擴展字段，后續(xù)單獨討論該字段作用。2.server_hello+server_certificate+sever_hello_done(a) server_hello, 服務(wù)端返回協(xié)商的信息結(jié)果，包括選擇使用的協(xié)議版本 version，選擇的加密套件 cipher su

3、ite，選擇的壓縮算法 compression method、隨機數(shù) random_S 等，其中隨機數(shù)用于后續(xù)的密鑰協(xié)商;(b)server_certificates, 服務(wù)器端配置對應(yīng)的證書鏈，用于身份驗證與密鑰交換;(c) server_hello_done，通知客戶端 server_hello 信息發(fā)送結(jié)束;3.證書校驗客戶端驗證證書的合法性，如果驗證通過才會進(jìn)行后續(xù)通信，否則根據(jù)錯誤情況不同做出提示和操作，合法性驗證包括如下：證書鏈的可信性 trusted certificate path，方法如前文所述;證書是否吊銷 revocation，有兩類方式離線 CRL 與在線 OCSP，不

4、同的客戶端行為會不同;有效期 expiry date，證書是否在有效時間范圍;域名 domain，核查證書域名是否與當(dāng)前的訪問域名匹配，匹配規(guī)則后續(xù)分析;4.client_key_exchange+change_cipher_spec+encrypted_handshake_message(a) client_key_exchange，合法性驗證通過之后，客戶端計算產(chǎn)生隨機數(shù)字 Pre-master，并用證書公鑰加密，發(fā)送給服務(wù)器;(b) 此時客戶端已經(jīng)獲取全部的計算協(xié)商密鑰需要的信息：兩個明文隨機數(shù) random_C 和 random_S 與自己計算產(chǎn)生的 Pre-master，計算得到協(xié)商

5、密鑰;enc_key=Fuc(random_C, random_S, Pre-Master)(c) change_cipher_spec（交換_密碼_模式），客戶端通知服務(wù)器后續(xù)的通信都采用協(xié)商的通信密鑰和加密算法進(jìn)行加密通信;(d) encrypted_handshake_message（加密握手消息），結(jié)合之前所有通信參數(shù)的 hash 值與其它相關(guān)信息生成一段數(shù)據(jù)，采用協(xié)商密鑰 session secret 與算法進(jìn)行加密，然后發(fā)送給服務(wù)器用于數(shù)據(jù)與握手驗證；5.change_cipher_spec+encrypted_handshake_message(a) 服務(wù)器用私鑰解密加密的 Pr

6、e-master 數(shù)據(jù)，基于之前交換的兩個明文隨機數(shù) random_C 和 random_S，計算得到協(xié)商密鑰:enc_key=Fuc(random_C, random_S, Pre-Master);(b) 計算之前所有接收信息的 hash 值，然后解密客戶端發(fā)送的 encrypted_handshake_message，驗證數(shù)據(jù)和密鑰正確性;(c) change_cipher_spec, 驗證通過之后，服務(wù)器同樣發(fā)送 change_cipher_spec 以告知客戶端后續(xù)的通信都采用協(xié)商的密鑰與算法進(jìn)行加密通信(d) encrypted_handshake_message, 服務(wù)器也結(jié)合所有

7、當(dāng)前的通信參數(shù)信息生成一段數(shù)據(jù)并采用協(xié)商密鑰 session secret 與算法加密并發(fā)送到客戶端;6.握手結(jié)束客戶端計算所有接收信息的 hash 值，并采用協(xié)商密鑰解密encrypted_handshake_message，驗證服務(wù)器發(fā)送的數(shù)據(jù)和密鑰，驗證通過則握手完成;7.加密通信開始使用協(xié)商密鑰與算法進(jìn)行加密通信。注意：(a) 服務(wù)器也可以要求驗證客戶端，即雙向認(rèn)證，可以在過程2要發(fā)送 client_certificate_request 信息，客戶端在過程4中先發(fā)送 client_certificate與certificate_verify_message 信息，證書的驗證方式基本相

8、同，certificate_verify_message 是采用client的私鑰加密的一段基于已經(jīng)協(xié)商的通信信息得到數(shù)據(jù)，服務(wù)器可以采用對應(yīng)的公鑰解密并驗證;(b) 根據(jù)使用的密鑰交換算法的不同，如 ECC 等，協(xié)商細(xì)節(jié)略有不同，總體相似;(c) sever key exchange 的作用是 server certificate 沒有攜帶足夠的信息時，發(fā)送給客戶端以計算 pre-master，如基于 DH 的證書，公鑰不被證書中包含，需要單獨發(fā)送;(d) change cipher spec 實際可用于通知對端改版當(dāng)前使用的加密通信方式，當(dāng)前沒有深入解析;(e) alter message

9、 用于指明在握手或通信過程中的狀態(tài)改變或錯誤信息，一般告警信息觸發(fā)條件是連接關(guān)閉，收到不合法的信息，信息解密失敗，用戶取消操作等，收到告警信息之后，通信會被斷開或者由接收方?jīng)Q定是否斷開連接。會話緩存握手過程為了加快建立握手的速度，減少協(xié)議帶來的性能降低和資源消耗(具體分析在后文)，TLS 協(xié)議有兩類會話緩存機制：會話標(biāo)識 session ID 與會話記錄 session ticket。session ID 由服務(wù)器端支持，協(xié)議中的標(biāo)準(zhǔn)字段，因此基本所有服務(wù)器都支持，服務(wù)器端保存會話ID以及協(xié)商的通信信息，Nginx 中1M 內(nèi)存約可以保存4000個 session ID 機器相關(guān)信息，占用服務(wù)

10、器資源較多;session ticket 需要服務(wù)器和客戶端都支持，屬于一個擴展字段，支持范圍約60%(無可靠統(tǒng)計與來源)，將協(xié)商的通信信息加密之后發(fā)送給客戶端保存，密鑰只有服務(wù)器知道，占用服務(wù)器資源很少。二者對比，主要是保存協(xié)商信息的位置與方式不同，類似與 http 中的 session 與 cookie。二者都存在的情況下，(nginx 實現(xiàn))優(yōu)先使用 session_ticket。握手過程如下圖：注意：雖然握手過程有1.5個來回，但是最后客戶端向服務(wù)器發(fā)送的第一條應(yīng)用數(shù)據(jù)不需要等待服務(wù)器返回的信息，因此握手延時是1*RTT。1.會話標(biāo)識 session ID(a) 如果客戶端和服務(wù)器之間

11、曾經(jīng)建立了連接，服務(wù)器會在握手成功后返回 session ID，并保存對應(yīng)的通信參數(shù)在服務(wù)器中;(b) 如果客戶端再次需要和該服務(wù)器建立連接，則在 client_hello 中 session ID 中攜帶記錄的信息，發(fā)送給服務(wù)器;(c) 服務(wù)器根據(jù)收到的 session ID 檢索緩存記錄，如果沒有檢索到貨緩存過期，則按照正常的握手過程進(jìn)行;(d) 如果檢索到對應(yīng)的緩存記錄，則返回 change_cipher_spec 與 encrypted_handshake_message 信息，兩個信息作用類似，encrypted_handshake_message 是到當(dāng)前的通信參數(shù)與 master

12、_secret的hash 值;(f) 如果客戶端能夠驗證通過服務(wù)器加密數(shù)據(jù)，則客戶端同樣發(fā)送 change_cipher_spec 與 encrypted_handshake_message 信息;(g) 服務(wù)器驗證數(shù)據(jù)通過，則握手建立成功，開始進(jìn)行正常的加密數(shù)據(jù)通信。2.會話記錄 session ticket(a) 如果客戶端和服務(wù)器之間曾經(jīng)建立了連接，服務(wù)器會在 new_session_ticket 數(shù)據(jù)中攜帶加密的 session_ticket 信息，客戶端保存;(b) 如果客戶端再次需要和該服務(wù)器建立連接，則在 client_hello 中擴展字段 session_ticket 中攜帶

13、加密信息，一起發(fā)送給服務(wù)器;(c) 服務(wù)器解密 sesssion_ticket 數(shù)據(jù)，如果能夠解密失敗，則按照正常的握手過程進(jìn)行;(d) 如果解密成功，則返回 change_cipher_spec 與 encrypted_handshake_message 信息，兩個信息作用與 session ID 中類似;(f) 如果客戶端能夠驗證通過服務(wù)器加密數(shù)據(jù)，則客戶端同樣發(fā)送 change_cipher_spec與encrypted_handshake_message 信息;(g) 服務(wù)器驗證數(shù)據(jù)通過，則握手建立成功，開始進(jìn)行正常的加密數(shù)據(jù)通信。重建連接重建連接 renegotiation 即放棄正

14、在使用的 TLS 連接，從新進(jìn)行身份認(rèn)證和密鑰協(xié)商的過程，特點是不需要斷開當(dāng)前的數(shù)據(jù)傳輸就可以重新身份認(rèn)證、更新密鑰或算法，因此服務(wù)器端存儲和緩存的信息都可以保持?？蛻舳撕头?wù)器都能夠發(fā)起重建連接的過程，當(dāng)前 windows 2000 & XP 與 SSL 2.0不支持。1.服務(wù)器重建連接服務(wù)器端重建連接一般情況是客戶端訪問受保護(hù)的數(shù)據(jù)時發(fā)生?；具^程如下：(a) 客戶端和服務(wù)器之間建立了有效 TLS 連接并通信;(b) 客戶端訪問受保護(hù)的信息;(c) 服務(wù)器端返回 hello_request 信息;(d) 客戶端收到 hello_request 信息之后發(fā)送 client_hello 信息，

15、開始重新建立連接。2.客戶端重建連接客戶端重建連接一般是為了更新通信密鑰。(a) 客戶端和服務(wù)器之間建立了有效 TLS 連接并通信;(b) 客戶端需要更新密鑰，主動發(fā)出 client_hello 信息;(c) 服務(wù)器端收到 client_hello 信息之后無法立即識別出該信息非應(yīng)用數(shù)據(jù)，因此會提交給下一步處理，處理完之后會返回通知該信息為要求重建連接;(d) 在確定重建連接之前，服務(wù)器不會立即停止向客戶端發(fā)送數(shù)據(jù)，可能恰好同時或有緩存數(shù)據(jù)需要發(fā)送給客戶端，但是客戶端不會再發(fā)送任何信息給服務(wù)器;(e) 服務(wù)器識別出重建連接請求之后，發(fā)送 server_hello 信息至客戶端;(f) 客戶端也

16、同樣無法立即判斷出該信息非應(yīng)用數(shù)據(jù)，同樣提交給下一步處理，處理之后會返回通知該信息為要求重建連接;(g) 客戶端和服務(wù)器開始新的重建連接的過程。密鑰計算上節(jié)提到了兩個明文傳輸?shù)碾S機數(shù) random_C 和 random_S 與通過加密在服務(wù)器和客戶端之間交換的 Pre-master，三個參數(shù)作為密鑰協(xié)商的基礎(chǔ)。本節(jié)討論說明密鑰協(xié)商的基本計算過程以及通信過程中的密鑰使用。1.計算 Key涉及參數(shù) random client 和 random server, Pre-master, Master secret, key material, 計算密鑰時，服務(wù)器和客戶端都具有這些基本信息，交換方式在上

17、節(jié)中有說明，計算流程如下：(a) 客戶端采用 RSA 或 Diffie-Hellman 等加密算法生成 Pre-master;(b) Pre-master 結(jié)合 random client 和 random server 兩個隨機數(shù)通過 PseudoRandomFunction(PRF)計算得到 Master secret;(c) Master secret 結(jié)合 random client 和 random server 兩個隨機數(shù)通過迭代計算得到 Key material;以下為一些重要的記錄，可以解決部分愛深入研究朋友的疑惑，copy的材料，分享給大家：(a) PreMaster sec

18、ret 前兩個字節(jié)是 TLS 的版本號，這是一個比較重要的用來核對握手?jǐn)?shù)據(jù)的版本號，因為在 Client Hello 階段，客戶端會發(fā)送一份加密套件列表和當(dāng)前支持的 SSL/TLS 的版本號給服務(wù)端，而且是使用明文傳送的，如果握手的數(shù)據(jù)包被破解之后，攻擊者很有可能串改數(shù)據(jù)包，選擇一個安全性較低的加密套件和版本給服務(wù)端，從而對數(shù)據(jù)進(jìn)行破解。所以，服務(wù)端需要對密文中解密出來對的 PreMaster 版本號跟之前 Client Hello 階段的版本號進(jìn)行對比，如果版本號變低，則說明被串改，則立即停止發(fā)送任何消息。(copy)(b) 不管是客戶端還是服務(wù)器，都需要隨機數(shù)，這樣生成的密鑰才不會每次都一

19、樣。由于 SSL 協(xié)議中證書是靜態(tài)的，因此十分有必要引入一種隨機因素來保證協(xié)商出來的密鑰的隨機性。對于 RSA 密鑰交換算法來說，pre-master-key 本身就是一個隨機數(shù)，再加上 hello 消息中的隨機，三個隨機數(shù)通過一個密鑰導(dǎo)出器最終導(dǎo)出一個對稱密鑰。pre master 的存在在于 SSL 協(xié)議不信任每個主機都能產(chǎn)生完全隨機的隨機數(shù)，如果隨機數(shù)不隨機，那么 pre master secret 就有可能被猜出來，那么僅適用 pre master secret 作為密鑰就不合適了，因此必須引入新的隨機因素，那么客戶端和服務(wù)器加上 pre master secret 三個隨機數(shù)一同生成

20、的密鑰就不容易被猜出了，一個偽隨機可能完全不隨機，可是三個偽隨機就十分接近隨機了，每增加一個自由度，隨機性增加的可不是一。2.密鑰使用Key 經(jīng)過12輪迭代計算會獲取到12個 hash 值，分組成為6個元素，列表如下：(a) mac key、encryption key 和 IV 是一組加密元素，分別被客戶端和服務(wù)器使用，但是這兩組元素都被兩邊同時獲取;(b) 客戶端使用 client 組元素加密數(shù)據(jù)，服務(wù)器使用 client 元素解密;服務(wù)器使用 server 元素加密，client 使用 server 元素解密;(c) 雙向通信的不同方向使用的密鑰不同，破解通信至少需要破解兩次;(d) e

21、ncryption key 用于對稱加密數(shù)據(jù);(e) IV 作為很多加密算法的初始化向量使用，具體可以研究對稱加密算法;(f) Mac key 用于數(shù)據(jù)的完整性校驗;4.4 數(shù)據(jù)加密通信過程(a) 對應(yīng)用層數(shù)據(jù)進(jìn)行分片成合適的 block;(b) 為分片數(shù)據(jù)編號，防止重放攻擊;(c) 使用協(xié)商的壓縮算法壓縮數(shù)據(jù);(d) 計算 MAC 值和壓縮數(shù)據(jù)組成傳輸數(shù)據(jù);(e) 使用 client encryption key 加密數(shù)據(jù)，發(fā)送給服務(wù)器 server;(f) server 收到數(shù)據(jù)之后使用 client encrytion key 解密，校驗數(shù)據(jù)，解壓縮數(shù)據(jù)，重新組裝。注：MAC值的計算包括兩個 Hash 值：client Mac key 和 Hash (編號、包類型、長度、壓縮數(shù)據(jù))。抓包分析關(guān)于抓包不再詳細(xì)分析，按照前面的分析，基本的情況都能夠匹配，根據(jù)平常定位問