1、握手與密鑰協(xié)商過(guò)程

基于RSA握手和密鑰交換的客戶端驗(yàn)證服務(wù)器為示例詳解TLS/SSL握手過(guò)程

?

再看一張手繪時(shí)序圖

(1).client_hello
? ? 客戶端發(fā)起請(qǐng)求，以明文傳輸請(qǐng)求信息，包含版本信息，加密套件候選列表，壓縮算法候選列表，隨機(jī)數(shù)，擴(kuò)展字段等信息，相關(guān)信息如下：
? ????支持的最高TSL協(xié)議版本version，從低到高依次 SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2，當(dāng)前基本不再使用低于 TLSv1 的版本;
? ????客戶端支持的加密套件 cipher suites 列表， 每個(gè)加密套件對(duì)應(yīng)前面 TLS 原理中的四個(gè)功能的組合：認(rèn)證算法 Au (身份驗(yàn)證)、密鑰交換算法 KeyExchange(密鑰協(xié)商)、對(duì)稱加密算法 Enc (信息加密)和信息摘要 Mac(完整性校驗(yàn));
? ????支持的壓縮算法 compression methods 列表，用于后續(xù)的信息壓縮傳輸;
? ????隨機(jī)數(shù) random_C，用于后續(xù)的密鑰的生成;
? ????擴(kuò)展字段 extensions，支持協(xié)議與算法的相關(guān)參數(shù)以及其它輔助信息等，常見(jiàn)的 SNI 就屬于擴(kuò)展字段，后續(xù)單獨(dú)討論該字段作用。
(2).server_hello+server_certificate+sever_hello_done
? ? ??server_hello, 服務(wù)端返回協(xié)商的信息結(jié)果，包括選擇使用的協(xié)議版本 version，選擇的加密套件 cipher suite，選擇的壓縮算法 compression method、隨機(jī)數(shù) random_S 等，其中隨機(jī)數(shù)用于后續(xù)的密鑰協(xié)商;
? ????server_certificates, 服務(wù)器端配置對(duì)應(yīng)的證書(shū)鏈，用于身份驗(yàn)證與密鑰交換;
? ????server_hello_done，通知客戶端 server_hello 信息發(fā)送結(jié)束;

(3).證書(shū)校驗(yàn)
? ??客戶端驗(yàn)證證書(shū)的合法性，如果驗(yàn)證通過(guò)才會(huì)進(jìn)行后續(xù)通信，否則根據(jù)錯(cuò)誤情況不同做出提示和操作，合法性驗(yàn)證包括如下：
? ????[證書(shū)鏈]的可信性 trusted certificate path，方法如前文所述;
? ????證書(shū)是否吊銷 revocation，有兩類方式離線 CRL 與在線 OCSP，不同的客戶端行為會(huì)不同;
? ????有效期 expiry date，證書(shū)是否在有效時(shí)間范圍;
? ????域名 domain，核查證書(shū)域名是否與當(dāng)前的訪問(wèn)域名匹配，匹配規(guī)則后續(xù)分析;
(4).client_key_exchange+change_cipher_spec+encrypted_handshake_message
? ??(a) client_key_exchange，合法性驗(yàn)證通過(guò)之后，客戶端計(jì)算產(chǎn)生隨機(jī)數(shù)字 Pre-master，并用證書(shū)公鑰加密，發(fā)送給服務(wù)器;
? ??(b) 此時(shí)客戶端已經(jīng)獲取全部的計(jì)算協(xié)商密鑰需要的信息：兩個(gè)明文隨機(jī)數(shù) random_C 和 random_S 與自己計(jì)算產(chǎn)生的 Pre-master，計(jì)算得到協(xié)商密鑰;
? ??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ù)與握手驗(yàn)證;
(5).change_cipher_spec+encrypted_handshake_message
? ??(a) 服務(wù)器用私鑰解密加密的 Pre-master 數(shù)據(jù)，基于之前交換的兩個(gè)明文隨機(jī)數(shù) random_C 和 random_S，計(jì)算得到協(xié)商密鑰:enc_key=Fuc(random_C, random_S, Pre-Master);
? ??(b) 計(jì)算之前所有接收信息的 hash 值，然后解密客戶端發(fā)送的 encrypted_handshake_message，驗(yàn)證數(shù)據(jù)和密鑰正確性;
? ??(c) change_cipher_spec, 驗(yàn)證通過(guò)之后，服務(wù)器同樣發(fā)送 change_cipher_spec 以告知客戶端后續(xù)的通信都采用協(xié)商的密鑰與算法進(jìn)行加密通信;
? ??(d) encrypted_handshake_message, 服務(wù)器也結(jié)合所有當(dāng)前的通信參數(shù)信息生成一段數(shù)據(jù)并采用協(xié)商密鑰 session secret 與算法加密并發(fā)送到客戶端;

(6).握手結(jié)束
? ??客戶端計(jì)算所有接收信息的 hash 值，并采用協(xié)商密鑰解密 encrypted_handshake_message，驗(yàn)證服務(wù)器發(fā)送的數(shù)據(jù)和密鑰，驗(yàn)證通過(guò)則握手完成;
(7).加密通信
? ??開(kāi)始使用協(xié)商密鑰與算法進(jìn)行加密通信。
注意：
? ??(a) 服務(wù)器也可以要求驗(yàn)證客戶端，即雙向認(rèn)證，可以在過(guò)程2要發(fā)送 client_certificate_request 信息，客戶端在過(guò)程4中先發(fā)送 client_certificate與certificate_verify_message 信息，證書(shū)的驗(yàn)證方式基本相同，certificate_verify_message 是采用client的私鑰加密的一段基于已經(jīng)協(xié)商的通信信息得到數(shù)據(jù)，服務(wù)器可以采用對(duì)應(yīng)的公鑰解密并驗(yàn)證;
? ??(b) 根據(jù)使用的密鑰交換算法的不同，如 ECC 等，協(xié)商細(xì)節(jié)略有不同，總體相似;
? ??(c) sever key exchange 的作用是 server certificate 沒(méi)有攜帶足夠的信息時(shí)，發(fā)送給客戶端以計(jì)算 pre-master，如基于 DH 的證書(shū)，公鑰不被證書(shū)中包含，需要單獨(dú)發(fā)送;
? ??(d) change cipher spec 實(shí)際可用于通知對(duì)端改版當(dāng)前使用的加密通信方式，當(dāng)前沒(méi)有深入解析;
? ??(e) alter message 用于指明在握手或通信過(guò)程中的狀態(tài)改變或錯(cuò)誤信息，一般告警信息觸發(fā)條件是連接關(guān)閉，收到不合法的信息，信息解密失敗，用戶取消操作等，收到告警信息之后，通信會(huì)被斷開(kāi)或者由接收方?jīng)Q定是否斷開(kāi)連接。

?

2、會(huì)話緩存握手過(guò)程

? ??為了加快建立握手的速度，減少協(xié)議帶來(lái)的性能降低和資源消耗(具體分析在后文)，TLS 協(xié)議有兩類會(huì)話緩存機(jī)制：會(huì)話標(biāo)識(shí) session ID 與會(huì)話記錄 session ticket。
? ??session ID 由服務(wù)器端支持，協(xié)議中的標(biāo)準(zhǔn)字段，因此基本所有服務(wù)器都支持，服務(wù)器端保存會(huì)話ID以及協(xié)商的通信信息，Nginx 中1M 內(nèi)存約可以保存4000個(gè) session ID 機(jī)器相關(guān)信息，占用服務(wù)器資源較多;
? ??session ticket 需要服務(wù)器和客戶端都支持，屬于一個(gè)擴(kuò)展字段，支持范圍約60%(無(wú)可靠統(tǒng)計(jì)與來(lái)源)，將協(xié)商的通信信息加密之后發(fā)送給客戶端保存，密鑰只有服務(wù)器知道，占用服務(wù)器資源很少。
? ??二者對(duì)比，主要是保存協(xié)商信息的位置與方式不同，類似與 http 中的 session 與 cookie。
? ??二者都存在的情況下，(nginx 實(shí)現(xiàn))優(yōu)先使用 session_ticket。
? ??握手過(guò)程如下圖:

?

注意：雖然握手過(guò)程有1.5個(gè)來(lái)回，但是最后客戶端向服務(wù)器發(fā)送的第一條應(yīng)用數(shù)據(jù)不需要等待服務(wù)器返回的信息，因此握手延時(shí)是1*RTT。
(1).會(huì)話標(biāo)識(shí) session ID
? ??(a) 如果客戶端和服務(wù)器之間曾經(jīng)建立了連接，服務(wù)器會(huì)在握手成功后返回 session ID，并保存對(duì)應(yīng)的通信參數(shù)在服務(wù)器中;
? ??(b) 如果客戶端再次需要和該服務(wù)器建立連接，則在 client_hello 中 session ID 中攜帶記錄的信息，發(fā)送給服務(wù)器;
? ??(c) 服務(wù)器根據(jù)收到的 session ID 檢索緩存記錄，如果沒(méi)有檢索到貨緩存過(guò)期，則按照正常的握手過(guò)程進(jìn)行;
? ??(d) 如果檢索到對(duì)應(yīng)的緩存記錄，則返回 change_cipher_spec 與 encrypted_handshake_message 信息，兩個(gè)信息作用類似，encrypted_handshake_message 是到當(dāng)前的通信參數(shù)與 master_secret的hash 值;
? ??(f) 如果客戶端能夠驗(yàn)證通過(guò)服務(wù)器加密數(shù)據(jù)，則客戶端同樣發(fā)送 change_cipher_spec 與 encrypted_handshake_message 信息;
? ??(g) 服務(wù)器驗(yàn)證數(shù)據(jù)通過(guò)，則握手建立成功，開(kāi)始進(jìn)行正常的加密數(shù)據(jù)通信。
(2).會(huì)話記錄 session ticket
? ??(a) 如果客戶端和服務(wù)器之間曾經(jīng)建立了連接，服務(wù)器會(huì)在 new_session_ticket 數(shù)據(jù)中攜帶加密的 session_ticket 信息，客戶端保存;
? ??(b) 如果客戶端再次需要和該服務(wù)器建立連接，則在 client_hello 中擴(kuò)展字段 session_ticket 中攜帶加密信息，一起發(fā)送給服務(wù)器;
? ??(c) 服務(wù)器解密 sesssion_ticket 數(shù)據(jù)，如果能夠解密失敗，則按照正常的握手過(guò)程進(jìn)行;
? ??(d) 如果解密成功，則返回 change_cipher_spec 與 encrypted_handshake_message 信息，兩個(gè)信息作用與 session ID 中類似;
? ??(f)如果客戶端能夠驗(yàn)證通過(guò)服務(wù)器加密數(shù)據(jù)，則客戶端同樣發(fā)送 change_cipher_spec與encrypted_handshake_message 信息;
? ??(g) 服務(wù)器驗(yàn)證數(shù)據(jù)通過(guò)，則握手建立成功，開(kāi)始進(jìn)行正常的加密數(shù)據(jù)通信。

?

3、重建連接

? ??重建連接 renegotiation 即放棄正在使用的 TLS 連接，從新進(jìn)行身份認(rèn)證和密鑰協(xié)商的過(guò)程，特點(diǎn)是不需要斷開(kāi)當(dāng)前的數(shù)據(jù)傳輸就可以重新身份認(rèn)證、更新密鑰或算法，因此服務(wù)器端存儲(chǔ)和緩存的信息都可以保持?？蛻舳撕头?wù)器都能夠發(fā)起重建連接的過(guò)程，當(dāng)前 windows 2000 & XP 與 SSL 2.0不支持。
(1).服務(wù)器重建連接

?

? ??服務(wù)器端重建連接一般情況是客戶端訪問(wèn)受保護(hù)的數(shù)據(jù)時(shí)發(fā)生?；具^(guò)程如下：
? ??(a) 客戶端和服務(wù)器之間建立了有效 TLS 連接并通信;
? ??(b) 客戶端訪問(wèn)受保護(hù)的信息;
? ??(c) 服務(wù)器端返回 hello_request 信息;
? ??(d) 客戶端收到 hello_request 信息之后發(fā)送 client_hello 信息，開(kāi)始重新建立連接。
(2).客戶端重建連接

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

4、密鑰計(jì)算

上節(jié)提到了兩個(gè)明文傳輸?shù)碾S機(jī)數(shù) random_C 和 random_S 與通過(guò)加密在服務(wù)器和客戶端之間交換的 Pre-master，三個(gè)參數(shù)作為密鑰協(xié)商的基礎(chǔ)。本節(jié)討論說(shuō)明密鑰協(xié)商的基本計(jì)算過(guò)程以及通信過(guò)程中的密鑰使用。
(1).計(jì)算 Key
涉及參數(shù) random client 和 random server, Pre-master, Master secret, key material, 計(jì)算密鑰時(shí)，服務(wù)器和客戶端都具有這些基本信息，交換方式在上節(jié)中有說(shuō)明，計(jì)算流程如下：

?

? ??(a) 客戶端采用 RSA 或 Diffie-Hellman 等加密算法生成 Pre-master;
? ??(b) Pre-master 結(jié)合 random client 和 random server 兩個(gè)隨機(jī)數(shù)通過(guò) PseudoRandomFunction(PRF)計(jì)算得到 Master secret;
? ??(c) Master secret 結(jié)合 random client 和 random server 兩個(gè)隨機(jī)數(shù)通過(guò)迭代計(jì)算得到 Key material;
以下為一些重要的記錄，可以解決部分愛(ài)深入研究朋友的疑惑，copy的材料，分享給大家：
? ??(a) PreMaster secret 前兩個(gè)字節(jié)是 TLS 的版本號(hào)，這是一個(gè)比較重要的用來(lái)核對(duì)握手?jǐn)?shù)據(jù)的版本號(hào)，因?yàn)樵?Client Hello 階段，客戶端會(huì)發(fā)送一份加密套件列表和當(dāng)前支持的 SSL/TLS 的版本號(hào)給服務(wù)端，而且是使用明文傳送的，如果握手的數(shù)據(jù)包被破解之后，攻擊者很有可能串改數(shù)據(jù)包，選擇一個(gè)安全性較低的加密套件和版本給服務(wù)端，從而對(duì)數(shù)據(jù)進(jìn)行破解。所以，服務(wù)端需要對(duì)密文中解密出來(lái)對(duì)的 PreMaster 版本號(hào)跟之前 Client Hello 階段的版本號(hào)進(jìn)行對(duì)比，如果版本號(hào)變低，則說(shuō)明被串改，則立即停止發(fā)送任何消息。(copy)
? ??(b) 不管是客戶端還是服務(wù)器，都需要隨機(jī)數(shù)，這樣生成的密鑰才不會(huì)每次都一樣。由于 SSL 協(xié)議中證書(shū)是靜態(tài)的，因此十分有必要引入一種隨機(jī)因素來(lái)保證協(xié)商出來(lái)的密鑰的隨機(jī)性。
? ??對(duì)于 RSA 密鑰交換算法來(lái)說(shuō)，pre-master-key 本身就是一個(gè)隨機(jī)數(shù)，再加上 hello 消息中的隨機(jī)，三個(gè)隨機(jī)數(shù)通過(guò)一個(gè)密鑰導(dǎo)出器最終導(dǎo)出一個(gè)對(duì)稱密鑰。
? ??pre master 的存在在于 SSL 協(xié)議不信任每個(gè)主機(jī)都能產(chǎn)生完全隨機(jī)的隨機(jī)數(shù)，如果隨機(jī)數(shù)不隨機(jī)，那么 pre master secret 就有可能被猜出來(lái)，那么僅適用 pre master secret 作為密鑰就不合適了，因此必須引入新的隨機(jī)因素，那么客戶端和服務(wù)器加上 pre master secret 三個(gè)隨機(jī)數(shù)一同生成的密鑰就不容易被猜出了，一個(gè)偽隨機(jī)可能完全不隨機(jī)，可是三個(gè)偽隨機(jī)就十分接近隨機(jī)了，每增加一個(gè)自由度，隨機(jī)性增加的可不是一。
(2).密鑰使用
? ??Key 經(jīng)過(guò)12輪迭代計(jì)算會(huì)獲取到12個(gè) hash 值，分組成為6個(gè)元素，列表如下：

? ??(a) mac key、encryption key 和 IV 是一組加密元素，分別被客戶端和服務(wù)器使用，但是這兩組元素都被兩邊同時(shí)獲取;
? ??(b) 客戶端使用 client 組元素加密數(shù)據(jù)，服務(wù)器使用 client 元素解密;服務(wù)器使用 server 元素加密，client 使用 server 元素解密;
? ??(c) 雙向通信的不同方向使用的密鑰不同，破解通信至少需要破解兩次;
? ??(d) encryption key 用于對(duì)稱加密數(shù)據(jù);
? ??(e) IV 作為很多加密算法的初始化向量使用，具體可以研究對(duì)稱加密算法;
? ??(f) Mac key 用于數(shù)據(jù)的完整性校驗(yàn);
（3）.數(shù)據(jù)加密通信過(guò)程
? ? (a) 對(duì)應(yīng)用層數(shù)據(jù)進(jìn)行分片成合適的 block;
? ??(b) 為分片數(shù)據(jù)編號(hào)，防止重放攻擊;
? ??(c) 使用協(xié)商的壓縮算法壓縮數(shù)據(jù);
? ??(d) 計(jì)算 MAC 值和壓縮數(shù)據(jù)組成傳輸數(shù)據(jù);
? ??(e) 使用 client encryption key 加密數(shù)據(jù)，發(fā)送給服務(wù)器 server;
? ??(f) server 收到數(shù)據(jù)之后使用 client encrytion key 解密，校驗(yàn)數(shù)據(jù)，解壓縮數(shù)據(jù)，重新組裝。
注：MAC值的計(jì)算包括兩個(gè) Hash 值：client Mac key 和 Hash (編號(hào)、包類型、長(zhǎng)度、壓縮數(shù)據(jù))。

?

5、抓包分析

關(guān)于抓包不再詳細(xì)分析，按照前面的分析，基本的情況都能夠匹配，根據(jù)平常定位問(wèn)題的過(guò)程，個(gè)人提些認(rèn)為需要注意的地方：
? ??(1).抓包 HTTP 通信，能夠清晰的看到通信的頭部和信息的明文，但是 HTTPS 是加密通信，無(wú)法看到 HTTP 協(xié)議的相關(guān)頭部和數(shù)據(jù)的明文信息，
? ??(2).抓包 HTTPS 通信主要包括三個(gè)過(guò)程：TCP 建立連接、TLS 握手、TLS 加密通信，主要分析 HTTPS 通信的握手建立和狀態(tài)等信息。
? ??(3).client_hello
根據(jù) version 信息能夠知道客戶端支持的最高的協(xié)議版本號(hào)，如果是 SSL 3.0 或 TLS 1.0 等低版本協(xié)議，非常注意可能因?yàn)榘姹镜鸵鹨恍┪帐质〉那闆r;
根據(jù) extension 字段中的 server_name 字段判斷是否支持SNI，存在則支持，否則不支持，對(duì)于定位握手失敗或證書(shū)返回錯(cuò)誤非常有用;
會(huì)話標(biāo)識(shí) session ID 是標(biāo)準(zhǔn)協(xié)議部分，如果沒(méi)有建立過(guò)連接則對(duì)應(yīng)值為空，不為空則說(shuō)明之前建立過(guò)對(duì)應(yīng)的連接并緩存;
會(huì)話記錄 session ticke t是擴(kuò)展協(xié)議部分，存在該字段說(shuō)明協(xié)議支持 sesssion ticket，否則不支持，存在且值為空，說(shuō)明之前未建立并緩存連接，存在且值不為空，說(shuō)明有緩存連接。
? ? (4).server_hello
? ??根據(jù) TLS version 字段能夠推測(cè)出服務(wù)器支持的協(xié)議的最高版本，版本不同可能造成握手失敗;
? ??基于 cipher_suite 信息判斷出服務(wù)器優(yōu)先支持的加密協(xié)議;
? ? (5).ceritficate
? ??服務(wù)器配置并返回的證書(shū)鏈，根據(jù)證書(shū)信息并于服務(wù)器配置文件對(duì)比，判斷請(qǐng)求與期望是否一致，如果不一致，是否返回的默認(rèn)證書(shū)。
? ? (6).alert
? ??告警信息 alert 會(huì)說(shuō)明建立連接失敗的原因即告警類型

《新程序員》：云原生和全面數(shù)字化實(shí)踐50位技術(shù)專家共同創(chuàng)作，文字、視頻、音頻交互閱讀

總結(jié)

以上是生活随笔為你收集整理的SSL/TLS握手过程的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。