本文大部分內(nèi)容摘自：http://www.wosign.com/faq/faq2016-0309-04.htm 尊重知識(shí)產(chǎn)權(quán)，轉(zhuǎn)載注明
1相赁、握手與密鑰協(xié)商過程
基于RSA握手和密鑰交換的客戶端驗(yàn)證服務(wù)器為示例詳解TLS/SSL握手過程
再看一張手繪時(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ù)以及其它輔助信息等恢总，常見的 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)證通過才會(huì)進(jìn)行后續(xù)通信，否則根據(jù)錯(cuò)誤情況不同做出提示和操作，合法性驗(yàn)證包括如下：
- [證書鏈]的可信性 trusted certificate path唠帝，方法如前文所述;
- 證書是否吊銷 revocation，有兩類方式離線 CRL 與在線 OCSP，不同的客戶端行為會(huì)不同;
- 有效期 expiry date，證書是否在有效時(shí)間范圍;
- 域名 domain勤讽，核查證書域名是否與當(dāng)前的訪問域名匹配巢墅，匹配規(guī)則后續(xù)分析;
4. client_key_exchange+change_cipher_spec+encrypted_handshake_message
- client_key_exchange芹彬，合法性驗(yàn)證通過之后，客戶端計(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)證通過之后，服務(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)證通過則握手完成;
7.加密通信
開始使用協(xié)商密鑰與算法進(jìn)行加密通信沦偎。
注意：
- 服務(wù)器也可以要求驗(yàn)證客戶端侈询，即雙向認(rèn)證扭粱，可以在過程2要發(fā)送 client_certificate_request 信息博其，客戶端在過程4中先發(fā)送 client_certificate與certificate_verify_message 信息，證書的驗(yàn)證方式基本相同，certificate_verify_message 是采用client的私鑰加密的一段基于已經(jīng)協(xié)商的通信信息得到數(shù)據(jù)浪汪，服務(wù)器可以采用對(duì)應(yīng)的公鑰解密并驗(yàn)證;
- 根據(jù)使用的密鑰交換算法的不同，如 ECC 等，協(xié)商細(xì)節(jié)略有不同趣惠，總體相似;
- sever key exchange 的作用是 server certificate 沒有攜帶足夠的信息時(shí)猾瘸，發(fā)送給客戶端以計(jì)算 pre-master袜腥，如基于 DH 的證書，公鑰不被證書中包含，需要單獨(dú)發(fā)送;
- change cipher spec 實(shí)際可用于通知對(duì)端改版當(dāng)前使用的加密通信方式戳葵，當(dāng)前沒有深入解析;
- alter message 用于指明在握手或通信過程中的狀態(tài)改變或錯(cuò)誤信息绎秒，一般告警信息觸發(fā)條件是連接關(guān)閉，收到不合法的信息徘铝，信息解密失敗，用戶取消操作等，收到告警信息之后疚俱，通信會(huì)被斷開或者由接收方?jīng)Q定是否斷開連接。
2拇勃、會(huì)話緩存握手過程
為了加快建立握手的速度，減少協(xié)議帶來的性能降低和資源消耗(具體分析在后文)妓肢，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%(無可靠統(tǒng)計(jì)與來源)，將協(xié)商的通信信息加密之后發(fā)送給客戶端保存谈山，密鑰只有服務(wù)器知道鸽粉，占用服務(wù)器資源很少。
二者對(duì)比抓艳，主要是保存協(xié)商信息的位置與方式不同触机，類似與 http 中的 session 與 cookie。
二者都存在的情況下，(nginx 實(shí)現(xiàn))優(yōu)先使用 session_ticket儡首。
握手過程如下圖:
注意：
雖然握手過程有1.5個(gè)來回片任，但是最后客戶端向服務(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 檢索緩存記錄，如果沒有檢索到貨緩存過期舞竿，則按照正常的握手過程進(jìn)行;
- 如果檢索到對(duì)應(yīng)的緩存記錄京景，則返回 change_cipher_spec 與 encrypted_handshake_message 信息，兩個(gè)信息作用類似骗奖，encrypted_handshake_message 是到當(dāng)前的通信參數(shù)與 master_secret的hash 值;
- 如果客戶端能夠驗(yàn)證通過服務(wù)器加密數(shù)據(jù)确徙，則客戶端同樣發(fā)送 change_cipher_spec 與 encrypted_handshake_message 信息;
(g) 服務(wù)器驗(yàn)證數(shù)據(jù)通過，則握手建立成功执桌，開始進(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ù)椎木，如果能夠解密失敗违柏，則按照正常的握手過程進(jìn)行;
- 如果解密成功，則返回 change_cipher_spec 與 encrypted_handshake_message 信息香椎，兩個(gè)信息作用與 session ID 中類似;
- 如果客戶端能夠驗(yàn)證通過服務(wù)器加密數(shù)據(jù)漱竖，則客戶端同樣發(fā)送 change_cipher_spec與encrypted_handshake_message 信息;
- 服務(wù)器驗(yàn)證數(shù)據(jù)通過，則握手建立成功畜伐，開始進(jìn)行正常的加密數(shù)據(jù)通信馍惹。
3、重建連接
重建連接 renegotiation 即放棄正在使用的 TLS 連接玛界，從新進(jìn)行身份認(rèn)證和密鑰協(xié)商的過程万矾，特點(diǎn)是不需要斷開當(dāng)前的數(shù)據(jù)傳輸就可以重新身份認(rèn)證、更新密鑰或算法慎框，因此服務(wù)器端存儲(chǔ)和緩存的信息都可以保持良狈。客戶端和服務(wù)器都能夠發(fā)起重建連接的過程笨枯，當(dāng)前 windows 2000 & XP 與 SSL 2.0不支持薪丁。
服務(wù)器重建連接
服務(wù)器端重建連接一般情況是客戶端訪問受保護(hù)的數(shù)據(jù)時(shí)發(fā)生遇西。基本過程如下：
- 客戶端和服務(wù)器之間建立了有效 TLS 連接并通信;
- 客戶端訪問受保護(hù)的信息;
- 服務(wù)器端返回 hello_request 信息;
- 客戶端收到 hello_request 信息之后發(fā)送 client_hello 信息严嗜，開始重新建立連接粱檀。
客戶端重建連接
客戶端重建連接一般是為了更新通信密鑰。
- 客戶端和服務(wù)器之間建立了有效 TLS 連接并通信;
- 客戶端需要更新密鑰漫玄，主動(dòng)發(fā)出 client_hello 信息;
- 服務(wù)器端收到 client_hello 信息之后無法立即識(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 信息至客戶端;
- 客戶端也同樣無法立即判斷出該信息非應(yīng)用數(shù)據(jù)，同樣提交給下一步處理忆畅，處理之后會(huì)返回通知該信息為要求重建連接;
-
客戶端和服務(wù)器開始新的重建連接的過程衡未。圖片.png
