HTTPS協議詳解(一)：HTTPS基礎知識
HTTPS協議詳解(二)：TLS/SSL工作原理
HTTPS協議詳解(三)：PKI 體系
HTTPS協議詳解(四)：TLS/SSL握手過程
HTTPS協議詳解(五)：HTTPS性能與優化
1、握手與密鑰協商過程
基於RSA握手和密鑰交換的客戶端驗證服務器為示例詳解TLS/SSL握手過程
再看一張手繪時序圖
(1).client_hello
客戶端發起請求，以明文傳輸請求信息，包含版本信息，加密套件候選列表，壓縮算法候選列表，隨機數，擴展字段等信息，相關信息如下：
• 支持的最高TSL協議版本version，從低到高依次 SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2，當前基本不再使用低於 TLSv1 的版本;
• 客戶端支持的加密套件 cipher suites 列表， 每個加密套件對應前面 TLS 原理中的四個功能的組合：認證算法 Au (身份驗證)、密鑰交換算法 KeyExchange(密鑰協商)、對稱加密算法 Enc (信息加密)和信息摘要 Mac(完整性校驗);
• 支持的壓縮算法 compression methods 列表，用於后續的信息壓縮傳輸;
• 隨機數 random_C，用於后續的密鑰的生成;
• 擴展字段 extensions，支持協議與算法的相關參數以及其它輔助信息等，常見的 SNI 就屬於擴展字段，后續單獨討論該字段作用。
(2).server_hello+server_certificate+sever_hello_done
• server_hello, 服務端返回協商的信息結果，包括選擇使用的協議版本 version，選擇的加密套件 cipher suite，選擇的壓縮算法 compression method、隨機數 random_S 等，其中隨機數用於后續的密鑰協商;
• server_certificates, 服務器端配置對應的證書鏈，用於身份驗證與密鑰交換;
• server_hello_done，通知客戶端 server_hello 信息發送結束;
(3).證書校驗
客戶端驗證證書的合法性，如果驗證通過才會進行后續通信，否則根據錯誤情況不同做出提示和操作，合法性驗證包括如下：
• [證書鏈]的可信性 trusted certificate path，方法如前文所述;
• 證書是否吊銷 revocation，有兩類方式離線 CRL 與在線 OCSP，不同的客戶端行為會不同;
• 有效期 expiry date，證書是否在有效時間范圍;
• 域名 domain，核查證書域名是否與當前的訪問域名匹配，匹配規則后續分析;
(4).client_key_exchange+change_cipher_spec+encrypted_handshake_message
(a) client_key_exchange，合法性驗證通過之后，客戶端計算產生隨機數字 Pre-master，並用證書公鑰加密，發送給服務器;
(b) 此時客戶端已經獲取全部的計算協商密鑰需要的信息：兩個明文隨機數 random_C 和 random_S 與自己計算產生的 Pre-master，計算得到協商密鑰;
enc_key=Fuc(random_C, random_S, Pre-Master)
(c) change_cipher_spec，客戶端通知服務器后續的通信都采用協商的通信密鑰和加密算法進行加密通信;
(d) encrypted_handshake_message，結合之前所有通信參數的 hash 值與其它相關信息生成一段數據，采用協商密鑰 session secret 與算法進行加密，然后發送給服務器用於數據與握手驗證;
(5).change_cipher_spec+encrypted_handshake_message
(a) 服務器用私鑰解密加密的 Pre-master 數據，基於之前交換的兩個明文隨機數 random_C 和 random_S，計算得到協商密鑰:enc_key=Fuc(random_C, random_S, Pre-Master);
(b) 計算之前所有接收信息的 hash 值，然后解密客戶端發送的 encrypted_handshake_message，驗證數據和密鑰正確性;
(c) change_cipher_spec, 驗證通過之后，服務器同樣發送 change_cipher_spec 以告知客戶端后續的通信都采用協商的密鑰與算法進行加密通信;
(d) encrypted_handshake_message, 服務器也結合所有當前的通信參數信息生成一段數據並采用協商密鑰 session secret 與算法加密並發送到客戶端;
(6).握手結束
客戶端計算所有接收信息的 hash 值，並采用協商密鑰解密 encrypted_handshake_message，驗證服務器發送的數據和密鑰，驗證通過則握手完成;
(7).加密通信
開始使用協商密鑰與算法進行加密通信。
注意：
(a) 服務器也可以要求驗證客戶端，即雙向認證，可以在過程2要發送 client_certificate_request 信息，客戶端在過程4中先發送 client_certificate與certificate_verify_message 信息，證書的驗證方式基本相同，certificate_verify_message 是采用client的私鑰加密的一段基於已經協商的通信信息得到數據，服務器可以采用對應的公鑰解密並驗證;
(b) 根據使用的密鑰交換算法的不同，如 ECC 等，協商細節略有不同，總體相似;
(c) sever key exchange 的作用是 server certificate 沒有攜帶足夠的信息時，發送給客戶端以計算 pre-master，如基於 DH 的證書，公鑰不被證書中包含，需要單獨發送;
(d) change cipher spec 實際可用於通知對端改版當前使用的加密通信方式，當前沒有深入解析;
(e) alter message 用於指明在握手或通信過程中的狀態改變或錯誤信息，一般告警信息觸發條件是連接關閉，收到不合法的信息，信息解密失敗，用戶取消操作等，收到告警信息之后，通信會被斷開或者由接收方決定是否斷開連接。
2、會話緩存握手過程
為了加快建立握手的速度，減少協議帶來的性能降低和資源消耗(具體分析在后文)，TLS 協議有兩類會話緩存機制：會話標識 session ID 與會話記錄 session ticket。session ID 由服務器端支持，協議中的標准字段，因此基本所有服務器都支持，服務器端保存會話ID以及協商的通信信息，Nginx 中1M 內存約可以保存4000個 session ID 機器相關信息，占用服務器資源較多;
session ticket 需要服務器和客戶端都支持，屬於一個擴展字段，支持范圍約60%(無可靠統計與來源)，將協商的通信信息加密之后發送給客戶端保存，密鑰只有服務器知道，占用服務器資源很少。
二者對比，主要是保存協商信息的位置與方式不同，類似與 http 中的 session 與 cookie。
二者都存在的情況下，(nginx 實現)優先使用 session_ticket。
握手過程如下圖:
注意：雖然握手過程有1.5個來回，但是最后客戶端向服務器發送的第一條應用數據不需要等待服務器返回的信息，因此握手延時是1*RTT。
(1).會話標識 session ID
(a) 如果客戶端和服務器之間曾經建立了連接，服務器會在握手成功后返回 session ID，並保存對應的通信參數在服務器中;
(b) 如果客戶端再次需要和該服務器建立連接，則在 client_hello 中 session ID 中攜帶記錄的信息，發送給服務器;
(c) 服務器根據收到的 session ID 檢索緩存記錄，如果沒有檢索到貨緩存過期，則按照正常的握手過程進行;
(d) 如果檢索到對應的緩存記錄，則返回 change_cipher_spec 與 encrypted_handshake_message 信息，兩個信息作用類似，encrypted_handshake_message 是到當前的通信參數與 master_secret的hash 值;
(f) 如果客戶端能夠驗證通過服務器加密數據，則客戶端同樣發送 change_cipher_spec 與 encrypted_handshake_message 信息;
(g) 服務器驗證數據通過，則握手建立成功，開始進行正常的加密數據通信。
(2).會話記錄 session ticket
(a) 如果客戶端和服務器之間曾經建立了連接，服務器會在 new_session_ticket 數據中攜帶加密的 session_ticket 信息，客戶端保存;
(b) 如果客戶端再次需要和該服務器建立連接，則在 client_hello 中擴展字段 session_ticket 中攜帶加密信息，一起發送給服務器;
(c) 服務器解密 sesssion_ticket 數據，如果能夠解密失敗，則按照正常的握手過程進行;
(d) 如果解密成功，則返回 change_cipher_spec 與 encrypted_handshake_message 信息，兩個信息作用與 session ID 中類似;
(f)如果客戶端能夠驗證通過服務器加密數據，則客戶端同樣發送 change_cipher_spec與encrypted_handshake_message 信息;
(g) 服務器驗證數據通過，則握手建立成功，開始進行正常的加密數據通信。
3、重建連接
重建連接 renegotiation 即放棄正在使用的 TLS 連接，從新進行身份認證和密鑰協商的過程，特點是不需要斷開當前的數據傳輸就可以重新身份認證、更新密鑰或算法，因此服務器端存儲和緩存的信息都可以保持。客戶端和服務器都能夠發起重建連接的過程，當前 windows 2000 & XP 與 SSL 2.0不支持。(1).服務器重建連接
服務器端重建連接一般情況是客戶端訪問受保護的數據時發生。基本過程如下：
(a) 客戶端和服務器之間建立了有效 TLS 連接並通信;
(b) 客戶端訪問受保護的信息;
(c) 服務器端返回 hello_request 信息;
(d) 客戶端收到 hello_request 信息之后發送 client_hello 信息，開始重新建立連接。
(2).客戶端重建連接
客戶端重建連接一般是為了更新通信密鑰。
(a) 客戶端和服務器之間建立了有效 TLS 連接並通信;
(b) 客戶端需要更新密鑰，主動發出 client_hello 信息;
(c) 服務器端收到 client_hello 信息之后無法立即識別出該信息非應用數據，因此會提交給下一步處理，處理完之后會返回通知該信息為要求重建連接;
(d) 在確定重建連接之前，服務器不會立即停止向客戶端發送數據，可能恰好同時或有緩存數據需要發送給客戶端，但是客戶端不會再發送任何信息給服務器;
(e) 服務器識別出重建連接請求之后，發送 server_hello 信息至客戶端;
(f) 客戶端也同樣無法立即判斷出該信息非應用數據，同樣提交給下一步處理，處理之后會返回通知該信息為要求重建連接;
(g) 客戶端和服務器開始新的重建連接的過程。
4、密鑰計算
上節提到了兩個明文傳輸的隨機數 random_C 和 random_S 與通過加密在服務器和客戶端之間交換的 Pre-master，三個參數作為密鑰協商的基礎。本節討論說明密鑰協商的基本計算過程以及通信過程中的密鑰使用。(1).計算 Key
涉及參數 random client 和 random server, Pre-master, Master secret, key material, 計算密鑰時，服務器和客戶端都具有這些基本信息，交換方式在上節中有說明，計算流程如下：
(a) 客戶端采用 RSA 或 Diffie-Hellman 等加密算法生成 Pre-master;
(b) Pre-master 結合 random client 和 random server 兩個隨機數通過 PseudoRandomFunction(PRF)計算得到 Master secret;
(c) Master secret 結合 random client 和 random server 兩個隨機數通過迭代計算得到 Key material;
以下為一些重要的記錄，可以解決部分愛深入研究朋友的疑惑，copy的材料，分享給大家：
(a) PreMaster secret 前兩個字節是 TLS 的版本號，這是一個比較重要的用來核對握手數據的版本號，因為在 Client Hello 階段，客戶端會發送一份加密套件列表和當前支持的 SSL/TLS 的版本號給服務端，而且是使用明文傳送的，如果握手的數據包被破解之后，攻擊者很有可能串改數據包，選擇一個安全性較低的加密套件和版本給服務端，從而對數據進行破解。所以，服務端需要對密文中解密出來對的 PreMaster 版本號跟之前 Client Hello 階段的版本號進行對比，如果版本號變低，則說明被串改，則立即停止發送任何消息。(copy)
(b) 不管是客戶端還是服務器，都需要隨機數，這樣生成的密鑰才不會每次都一樣。由於 SSL 協議中證書是靜態的，因此十分有必要引入一種隨機因素來保證協商出來的密鑰的隨機性。
對於 RSA 密鑰交換算法來說，pre-master-key 本身就是一個隨機數，再加上 hello 消息中的隨機，三個隨機數通過一個密鑰導出器最終導出一個對稱密鑰。
pre master 的存在在於 SSL 協議不信任每個主機都能產生完全隨機的隨機數，如果隨機數不隨機，那么 pre master secret 就有可能被猜出來，那么僅適用 pre master secret 作為密鑰就不合適了，因此必須引入新的隨機因素，那么客戶端和服務器加上 pre master secret 三個隨機數一同生成的密鑰就不容易被猜出了，一個偽隨機可能完全不隨機，可是三個偽隨機就十分接近隨機了，每增加一個自由度，隨機性增加的可不是一。
(2).密鑰使用
Key 經過12輪迭代計算會獲取到12個 hash 值，分組成為6個元素，列表如下：
(a) mac key、encryption key 和 IV 是一組加密元素，分別被客戶端和服務器使用，但是這兩組元素都被兩邊同時獲取;
(b) 客戶端使用 client 組元素加密數據，服務器使用 client 元素解密;服務器使用 server 元素加密，client 使用 server 元素解密;
(c) 雙向通信的不同方向使用的密鑰不同，破解通信至少需要破解兩次;
(d) encryption key 用於對稱加密數據;
(e) IV 作為很多加密算法的初始化向量使用，具體可以研究對稱加密算法;
(f) Mac key 用於數據的完整性校驗;
（3）.數據加密通信過程
(a) 對應用層數據進行分片成合適的 block;
(b) 為分片數據編號，防止重放攻擊;
(c) 使用協商的壓縮算法壓縮數據;
(d) 計算 MAC 值和壓縮數據組成傳輸數據;
(e) 使用 client encryption key 加密數據，發送給服務器 server;
(f) server 收到數據之后使用 client encrytion key 解密，校驗數據，解壓縮數據，重新組裝。
注：MAC值的計算包括兩個 Hash 值：client Mac key 和 Hash (編號、包類型、長度、壓縮數據)。
5、抓包分析
關於抓包不再詳細分析，按照前面的分析，基本的情況都能夠匹配，根據平常定位問題的過程，個人提些認為需要注意的地方：(1).抓包 HTTP 通信，能夠清晰的看到通信的頭部和信息的明文，但是 HTTPS 是加密通信，無法看到 HTTP 協議的相關頭部和數據的明文信息，
(2).抓包 HTTPS 通信主要包括三個過程：TCP 建立連接、TLS 握手、TLS 加密通信，主要分析 HTTPS 通信的握手建立和狀態等信息。
(3).client_hello
根據 version 信息能夠知道客戶端支持的最高的協議版本號，如果是 SSL 3.0 或 TLS 1.0 等低版本協議，非常注意可能因為版本低引起一些握手失敗的情況;
根據 extension 字段中的 server_name 字段判斷是否支持SNI，存在則支持，否則不支持，對於定位握手失敗或證書返回錯誤非常有用;
會話標識 session ID 是標准協議部分，如果沒有建立過連接則對應值為空，不為空則說明之前建立過對應的連接並緩存;
會話記錄 session ticke t是擴展協議部分，存在該字段說明協議支持 sesssion ticket，否則不支持，存在且值為空，說明之前未建立並緩存連接，存在且值不為空，說明有緩存連接。
(4).server_hello
根據 TLS version 字段能夠推測出服務器支持的協議的最高版本，版本不同可能造成握手失敗;
基於 cipher_suite 信息判斷出服務器優先支持的加密協議;
(5).ceritficate
服務器配置並返回的證書鏈，根據證書信息並於服務器配置文件對比，判斷請求與期望是否一致，如果不一致，是否返回的默認證書。
(6).alert
告警信息 alert 會說明建立連接失敗的原因即告警類型，對於定位問題非常重要。