HTTPS之TLS1.3特性解析(四)

NO IMAGE

TLS1.2 已經是 10 年前(2008 年)的“老”協議了,雖然歷經考驗,但畢竟“歲月不饒人”,在安全、性能等方面已經跟不上如今的互聯網了。

於是經過四年、近 30 個草案的反覆打磨,TLS1.3 終於在前年(2018 年)“粉墨登場”,再次確立了信息安全領域的新標準。

我們先來快速瀏覽一下 TLS1.3 的三個主要改進目標:兼容、安全與性能

最大化兼容性

由於 1.1、1.2 等協議已經出現了很多年,很多應用軟件、中間代理(官方稱為“MiddleBox”)只認老的記錄協議格式,更新改造很困難,甚至是不可行(設備僵化)。

在早期的試驗中發現,一旦變更了記錄頭字段裡的版本號,也就是由 0x303(TLS1.2)改為 0x304(TLS1.3)的話,大量的代理服務器、網關都無法正確處理,最終導致 TLS 握手失敗。

為了保證這些被廣泛部署的“老設備”能夠繼續使用,避免新協議帶來的“衝擊”,TLS1.3 不得不做出妥協,保持現有的記錄格式不變,通過“偽裝”來實現兼容,使得 TLS1.3 看上去“像是”TLS1.2。

那麼,該怎麼區分 1.2 和 1.3 呢?

這要用到一個新的擴展協議(Extension Protocol),它有點“補充條款”的意思,通過在記錄末尾添加一系列的“擴展字段”來增加新的功能,老版本的 TLS 不認識它可以直接忽略,這就實現了“後向兼容”。

在記錄頭的 Version 字段被兼容性“固定”的情況下,只要是 TLS1.3 協議,握手的“Hello”消息後面就必須有“supported_versions”擴展,它標記了 TLS 的版本號,使用它就能區分新舊協議。

強化安全

TLS1.2 在十來年的應用中獲得了許多寶貴的經驗,陸續發現了很多的漏洞和加密算法的弱點,所以 TLS1.3 就在協議裡修補了這些不安全因素。

比如:

  • 偽隨機數函數由 PRF 升級為 HKDF(HMAC-based Extract-and-Expand Key Derivation Function);
  • 明確禁止在記錄協議裡使用壓縮;
  • 廢除了 RC4、DES 對稱加密算法;
  • 廢除了 ECB、CBC 等傳統分組模式;
  • 廢除了 MD5、SHA1、SHA-224 摘要算法;
  • 廢除了 RSA、DH 密鑰交換算法和許多命名曲線。

經過這一番“減肥瘦身”之後,TLS1.3 裡只保留了 AES、ChaCha20 對稱加密算法,分組模式只能用 AEAD 的 GCM、CCM 和 Poly1305,摘要算法只能用 SHA256、SHA384,密鑰交換算法只有 ECDHE 和 DHE,橢圓曲線也被“砍”到只剩 P-256 和 x25519 等 5 種。

減肥可以讓人變得更輕巧靈活,TLS 也是這樣。

算法精簡後帶來了一個意料之中的好處:原來眾多的算法、參數組合導致密碼套件非常複雜,難以選擇,而現在的 TLS1.3 裡只有 5 個套件,無論是客戶端還是服務器都不會再犯“選擇困難症”了。

HTTPS之TLS1.3特性解析(四)

提升性能

HTTPS 建立連接時除了要做 TCP 握手,還要做 TLS 握手,可能導致幾十毫秒甚至上百毫秒的延遲,在移動網絡中延遲還會更嚴重。

現在因為密碼套件大幅度簡化,也就沒有必要再像以前那樣走複雜的協商流程了。TLS1.3 壓縮了以前的“Hello”協商過程,刪除了“Key Exchange”消息,效率提高了一倍。

那麼它是怎麼做的呢?

其實具體的做法還是利用了擴展。客戶端在“Client Hello”消息裡直接用“supported_groups”帶上支持的曲線,比如 P-256、x25519,用“key_share”帶上曲線對應的客戶端公鑰參數,用“signature_algorithms”帶上簽名算法。

1.3握手圖

HTTPS之TLS1.3特性解析(四)

握手分析

HTTPS之TLS1.3特性解析(四)

小結

  1. 為了兼容 1.1、1.2 等“老”協議,TLS1.3 會“偽裝”成 TLS1.2,新特性在“擴展”裡實現;
  2. 1.1、1.2 在實踐中發現了很多安全隱患,所以 TLS1.3 大幅度刪減了加密算法,只保留了 ECDHE、AES、ChaCha20、SHA-2 等極少數算法,強化了安全;
  3. TLS1.3 也簡化了握手過程,完全握手只需要一個消息往返,提升了性能。

相關文章

手寫new

手寫call、apply、bind

ES6模塊和CommonJS模塊

同源策略