TLS握手秘鑰套件分析

本文轉載自查看原文 2019-06-26 11:12 595 論文資料整理/ 計算機網絡

1、為了弄清楚TLS1.3的內部結構，覺得有必要將TLS的整個結構從新整理一遍，方便后續在做握手協議的形式化分析的時候能夠不遺漏每個加密和認證的的環節。

TLS1.3不論文在協議內容上還是性能上都較之前的TLS1.2版本有較大的改變，這里首先概括性的表征一下存在的差異：

更換了新的密碼套件，舊的密碼套件不在支持TLS1.3，不提供鄉下兼容的特性。新的密碼套件一共五個如下：

TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_CCM_SHA256
TLS_AES_128_CCM_8_SHA256

同時新的密碼組定義不同，並未指定證書類型，秘鑰交換機制，客戶端在ClientHello中提供了key_Share，在主握手完成之后才能建立會話，在握手結束和會話建立之間存在間隙，在后續的會話恢復機制中可以產生影響。TLS1.3連接中不能重新協商。秘鑰改變之后不再像對方發送change_cipher_spec報文信息。更多的握手信息會被加密。更多類型的消息可以實現擴展，

TLS1.3徹底廢棄了RSA秘鑰交換算法，之前的1.2的版本先計算MAC再加密的方法存在很多安全隱患，不再允許對加密報文進行壓縮處理，TLS1.3棄用的加密算法如下：

SHA-1 Hash Function 存在安全隱患
RC4 Steam Cipher ----在HTTPS中使用並不安全
DES
3DES
AES-CBC
MD5 Algorithm
Various Diffie-Hellman groups
EXPORT-strength ciphers
RSA Key Transport --------不支持向前安全

LTS1.3 僅采用AEAD類對稱加密算法作為唯一的加密選項，同時引入了新的秘鑰協商機制 PSK（PreSharedKEy）

圖 TLS在傳輸層保障信息傳輸的安全示意圖

2、對TLS1.3 握手協議的過程分析

從效率性能上講，TLS1.2的版本握手需要協商多個參數，握手過程需要往返兩個（RTT），相比較1.3的版本在參數，秘鑰，秘鑰套件和往返次數上都減少。所以TLS1.3放棄了向后兼容的方法，轉而向更加安全的措施。

1、客戶端發送 ClientHello 消息
ClientHello---包含的信息---------{ 協議版本、DH秘鑰交換參數列表KeyShare 、隨機數 }
2、服務端回復 ServerHello消息
ServerHello-----包含信息-------{ 選定的加密套件、發送的證書給客戶端、使用證書私鑰對握手消息簽名、選用客戶端提供的參數生成ECDH臨時秘鑰、結合選定的DH參數計算出用於加密的共享秘鑰、服務端生成臨時公鑰通過 KeyShare 消息發送給客戶端 }
3、客戶端收到KeyShare 消息之后，使用證書的公鑰進行簽名驗證，獲取服務器端的ECDH臨時公鑰，生成會話所需要的公鑰秘鑰
4、雙方使用生成的共享秘鑰對消息加密傳輸，保證消息安全。

3、恢復會話過程

TLS1.3恢復會話可以直接發送加密后的應用數據，不需要額外的TLS握手，因此 “0-RTT” 握手就是指恢復加密傳輸層不需要二外的RTT，但是在第一次進行完全握手的時候，是需要 1-RTT的。但是存在的一個缺點是，TLS1.3 0-RTT現在無法保證向前安全（ForwardSecrecy），如果當攻擊者通過某種手段可以獲取到 Secession Ticket key ,攻擊者就可以解密之前的加密數據。（注意：環節該問題的辦法：可以通過設置 SeverConfiguration 和Expiration Date字段，使得與Session Ticket Key 相關的DH靜態參數在短時間內過期）

4、對TLS1.2 協議形式化分析的改進