wosign
----------------------------------專欄導航----------------------------------
https協議詳解(一)：https基礎知識
https協議詳解(二)：tls/ssl工作原理
https協議詳解(三)：pki 體系
https協議詳解(四)：tls/ssl握手過程
https協議詳解(五)：https效能與優化
客戶端發起請求，以明文傳輸請求資訊，包含版本資訊，加密套件候選列表，壓縮演算法候選列表，隨機數，擴充套件欄位等資訊，相關資訊如下：
• 支援的最高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 資訊傳送結束;
(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 與演算法加密併發送到客戶端;
客戶端計算所有接收資訊的 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 用於指明在握手或通訊過程中的狀態改變或錯誤資訊，一般告警資訊觸發條件是連線關閉，收到不合法的資訊，資訊解密失敗，使用者取消操作等，收到告警資訊之後，通訊會被斷開或者由接收方決定是否斷開連線。
(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) 伺服器驗證資料通過，則握手建立成功，開始進行正常的加密資料通訊。
4、金鑰計算
key 經過12輪迭代計算會獲取到12個 hash 值，分組成為6個元素，列表如下：
(a) 對應用層資料進行分片成合適的 block;
(b) 為分片資料編號，防止重放攻擊;
(c) 使用協商的壓縮演算法壓縮資料;
(d) 計算 mac 值和壓縮資料組成傳輸資料;
(e) 使用 client encryption key 加密資料，傳送給伺服器 server;
(f) server 收到資料之後使用 client encrytion key 解密，校驗資料，解壓縮資料，重新組裝。
注：mac值的計算包括兩個 hash 值：client mac key 和 hash (編號、包型別、長度、壓縮資料)。
5、抓包分析
wireshark抓包分析各協議
執行環境 kali linux 工具 wireshark 位址解析協議，即arp address resolution protocol 是根據ip位址獲取實體地址的乙個tcp ip協議。主機傳送資訊時將包含目標ip位址的arp請求廣播到網路上的所有主機，並接收返回訊息，以此確定目標的實體地址 收到...
說說TLS協議裡的wireshark抓包內容（一）
我們看到第63號 客戶端向伺服器傳送 client hello 資料報 我們觀察內容 先看到 content type 內容的格式 其實就是說這是握手協議中的 client hello tls中有四種協議 握手協議 22 這裡就是22可以看到 警告協議 21 密碼變更協議 20 這協議沒有出現在我們...
說說TLS協議裡的wireshark抓包內容（二）
第編號70的報文 這是伺服器第一次回給客戶端的第乙個報文 這個報文的內容是server hello 裡面包括了 內容是握手協議 和client hello 一樣 版本是tls v1.2 然後是握手協議的型別 server hello 接著是伺服器生成的隨機數 後面單獨說這個 伺服器生成的會話id 確...