本文大部分內(nèi)容摘自：http://www.wosign.com/faq/faq2016-0309-04.htm 尊重知識(shí)產(chǎn)權(quán)，轉(zhuǎn)載注明

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

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

圖片.png

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

image

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)的證書鏈，用于身份驗(yàn)證與密鑰交換;
• server_hello_done，通知客戶端 server_hello 信息發(fā)送結(jié)束;

3. 證書校驗(yàn)

客戶端驗(yàn)證證書的合法性，如果驗(yàn)證通過(guò)才會(huì)進(jìn)行后續(xù)通信，否則根據(jù)錯(cuò)誤情況不同做出提示和操作，合法性驗(yàn)證包括如下：

• [證書鏈]的可信性 trusted certificate path，方法如前文所述;
• 證書是否吊銷 revocation，有兩類方式離線 CRL 與在線 OCSP，不同的客戶端行為會(huì)不同;
• 有效期 expiry date，證書是否在有效時(shí)間范圍;
• 域名 domain，核查證書域名是否與當(dāng)前的訪問(wèn)域名匹配，匹配規(guī)則后續(xù)分析;

4. client_key_exchange+change_cipher_spec+encrypted_handshake_message

• client_key_exchange，合法性驗(yàn)證通過(guò)之后，客戶端計(jì)算產(chǎn)生隨機(jī)數(shù)字 Pre-master，并用證書公鑰加密，發(fā)送給服務(wù)器;
• 此時(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)
  

• change_cipher_spec，客戶端通知服務(wù)器后續(xù)的通信都采用協(xié)商的通信密鑰和加密算法進(jìn)行加密通信;
• 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

• 服務(wù)器用私鑰解密加密的 Pre-master 數(shù)據(jù)，基于之前交換的兩個(gè)明文隨機(jī)數(shù) random_C 和 random_S，計(jì)算得到協(xié)商密鑰:enc_key=Fuc(random_C, random_S, Pre-Master);
• 計(jì)算之前所有接收信息的 hash 值，然后解密客戶端發(fā)送的 encrypted_handshake_message，驗(yàn)證數(shù)據(jù)和密鑰正確性;
• change_cipher_spec, 驗(yàn)證通過(guò)之后，服務(wù)器同樣發(fā)送 change_cipher_spec 以告知客戶端后續(xù)的通信都采用協(xié)商的密鑰與算法進(jìn)行加密通信;
• 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)行加密通信。

注意：

1. 服務(wù)器也可以要求驗(yàn)證客戶端，即雙向認(rèn)證，可以在過(guò)程2要發(fā)送 client_certificate_request 信息，客戶端在過(guò)程4中先發(fā)送 client_certificate與certificate_verify_message 信息，證書的驗(yàn)證方式基本相同，certificate_verify_message 是采用client的私鑰加密的一段基于已經(jīng)協(xié)商的通信信息得到數(shù)據(jù)，服務(wù)器可以采用對(duì)應(yīng)的公鑰解密并驗(yàn)證;
2. 根據(jù)使用的密鑰交換算法的不同，如 ECC 等，協(xié)商細(xì)節(jié)略有不同，總體相似;
3. sever key exchange 的作用是 server certificate 沒(méi)有攜帶足夠的信息時(shí)，發(fā)送給客戶端以計(jì)算 pre-master，如基于 DH 的證書，公鑰不被證書中包含，需要單獨(dú)發(fā)送;
4. change cipher spec 實(shí)際可用于通知對(duì)端改版當(dāng)前使用的加密通信方式，當(dāng)前沒(méi)有深入解析;
5. 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ò)程如下圖:

image

注意：

雖然握手過(guò)程有1.5個(gè)來(lái)回，但是最后客戶端向服務(wù)器發(fā)送的第一條應(yīng)用數(shù)據(jù)不需要等待服務(wù)器返回的信息，因此握手延時(shí)是1*RTT。

(1).會(huì)話標(biāo)識(shí) session ID

• 如果客戶端和服務(wù)器之間曾經(jīng)建立了連接，服務(wù)器會(huì)在握手成功后返回 session ID，并保存對(duì)應(yīng)的通信參數(shù)在服務(wù)器中;
• 如果客戶端再次需要和該服務(wù)器建立連接，則在 client_hello 中 session ID 中攜帶記錄的信息，發(fā)送給服務(wù)器;
• 服務(wù)器根據(jù)收到的 session ID 檢索緩存記錄，如果沒(méi)有檢索到貨緩存過(guò)期，則按照正常的握手過(guò)程進(jìn)行;
• 如果檢索到對(duì)應(yīng)的緩存記錄，則返回 change_cipher_spec 與 encrypted_handshake_message 信息，兩個(gè)信息作用類似，encrypted_handshake_message 是到當(dāng)前的通信參數(shù)與 master_secret的hash 值;
• 如果客戶端能夠驗(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

• 如果客戶端和服務(wù)器之間曾經(jīng)建立了連接，服務(wù)器會(huì)在 new_session_ticket 數(shù)據(jù)中攜帶加密的 session_ticket 信息，客戶端保存;
• 如果客戶端再次需要和該服務(wù)器建立連接，則在 client_hello 中擴(kuò)展字段 session_ticket 中攜帶加密信息，一起發(fā)送給服務(wù)器;
• 服務(wù)器解密 sesssion_ticket 數(shù)據(jù)，如果能夠解密失敗，則按照正常的握手過(guò)程進(jìn)行;
• 如果解密成功，則返回 change_cipher_spec 與 encrypted_handshake_message 信息，兩個(gè)信息作用與 session ID 中類似;
• 如果客戶端能夠驗(yàn)證通過(guò)服務(wù)器加密數(shù)據(jù)，則客戶端同樣發(fā)送 change_cipher_spec與encrypted_handshake_message 信息;
• 服務(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不支持。

服務(wù)器重建連接

image

服務(wù)器端重建連接一般情況是客戶端訪問(wèn)受保護(hù)的數(shù)據(jù)時(shí)發(fā)生?；具^(guò)程如下：

• 客戶端和服務(wù)器之間建立了有效 TLS 連接并通信;
• 客戶端訪問(wèn)受保護(hù)的信息;
• 服務(wù)器端返回 hello_request 信息;
• 客戶端收到 hello_request 信息之后發(fā)送 client_hello 信息，開(kāi)始重新建立連接。

客戶端重建連接

圖片.png

客戶端重建連接一般是為了更新通信密鑰。

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

• 客戶端和服務(wù)器開(kāi)始新的重建連接的過(guò)程。
  圖片.png