一、爲了弄清楚TLS1.3的內部結構,以爲有必要將TLS的整個結構重新整理一遍,方便後續在作握手協議的形式化分析的時候可以不遺漏每一個加密和認證的的環節。git
TLS1.3不論文在協議內容上仍是性能上都較以前的TLS1.2版本有較大的改變,這裏首先歸納性的表徵一下存在的差別:github
更換了新的密碼套件,舊的密碼套件不在支持TLS1.3,不提供鄉下兼容的特性。新的密碼套件一共五個以下:算法
同時新的密碼組定義不一樣,並未指定證書類型,祕鑰交換機制,客戶端在ClientHello中提供了key_Share,在主握手完成以後才能創建會話,在握手結束和會話創建之間存在間隙,在後續的會話恢復機制中能夠產生影響。TLS1.3鏈接中不能從新協商。祕鑰改變以後再也不像對方發送change_cipher_spec報文信息。更多的握手信息會被加密。更多類型的消息能夠實現擴展 ,安全
TLS1.3完全廢棄了RSA祕鑰交換算法,以前的1.2的版本先計算MAC再加密的方法存在不少安全隱患,再也不容許對加密報文進行壓縮處理,TLS1.3棄用的加密算法以下:服務器
LTS1.3 僅採用AEAD類對稱加密算法做爲惟一的加密選項,同時引入了新的祕鑰協商機制 PSK(PreSharedKEy)less
圖 TLS在傳輸層保障信息傳輸的安全示意圖性能
二、對TLS1.3 握手協議的過程分析加密
從效率性能上講,TLS1.2的版本 握手須要協商多個參數,握手過程須要往返兩個(RTT),相比較1.3的版本在參數,祕鑰,祕鑰套件和往返次數上都減小。因此TLS1.3放棄了向後兼容的方法,轉而向更加安全的措施。.net
三、恢復會話過程orm
TLS1.3恢復會話能夠直接發送加密後的應用數據,不須要額外的TLS握手,所以 「0-RTT」 握手就是指恢復加密傳輸層不須要二外的RTT,可是在第一次進行徹底握手的時候,是須要 1-RTT的。可是存在的一個缺點是,TLS1.3 0-RTT如今沒法保證向前安全(ForwardSecrecy),若是當攻擊者經過某種手段能夠獲取到 Secession Ticket key ,攻擊者就能夠解密以前的加密數據。(注意:環節該問題的辦法: 能夠經過設置 SeverConfiguration 和Expiration Date字段,使得與Session Ticket Key 相關的DH靜態參數在短期內過時)
四、對TLS1.2 協議形式化分析的改進
TLS 1.2 握手示意圖
五、TLS1.3 協議形式化描述
形式化描述以前對TLS協議的握手過程要抽象出信息交互過程
TLS降級
TLS1.3 握手協議過程
參考文獻:
cn.bing.com TLS1.3/QUIC 是怎樣作到 0-RTT 的
https://timtaubert.de/blog/2015/11/more-privacy-less-latency-improved-handshakes-in-tls-13/
https://blog.cloudflare.com/tls-1-3-overview-and-q-and-a/
https://www.wolfssl.com/tls-1-3-performance-part-2-full-handshake-2/
https://crypto.stackexchange.com/questions/47423/tls1-3-encrypted-handshake
https://tlseminar.github.io/tls-13/