關於TSL握手

改內容爲轉載內容
[SSL/TLS握手過程]
HTTPS協議詳解(一)：HTTPS基礎知識 
HTTPS協議詳解(二)：TLS/SSL工做原理
HTTPS協議詳解(三)：PKI 體系
HTTPS協議詳解(四)：TLS/SSL握手過程
HTTPS協議詳解(五)：HTTPS性能與優化

一、握手與密鑰協商過程

基於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 用於指明在握手或通訊過程當中的狀態改變或錯誤信息，通常告警信息觸發條件是鏈接關閉，收到不合法的信息，信息解密失敗，用戶取消操做等，收到告警信息以後，通訊會被斷開或者由接收方決定是否斷開鏈接。

二、會話緩存握手過程

    爲了加快創建握手的速度，減小協議帶來的性能下降和資源消耗(具體分析在後文)，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) 服務器驗證數據經過，則握手創建成功，開始進行正常的加密數據通訊。

三、重建鏈接

    重建鏈接 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) 客戶端和服務器開始新的重建鏈接的過程。

四、密鑰計算

上節提到了兩個明文傳輸的隨機數 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 (編號、包類型、長度、壓縮數據)。

五、抓包分析

關於抓包再也不詳細分析，按照前面的分析，基本的狀況都可以匹配，根據日常定位問題的過程，我的提些認爲須要注意的地方：
    (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 會說明創建鏈接失敗的緣由即告警類型，對於定位問題很是重要。

天天一點成長，歡迎指正！