HTTPS之TLS1.3特性解析（四）

TLS1.2 已是 10 年前（2008 年）的「老」協議了，雖然歷經考驗，但畢竟「歲月不饒人」，在安全、性能等方面已經跟不上現在的互聯網了。

因而通過四年、近 30 個草案的反覆打磨，TLS1.3 終於在前年（2018 年）「粉墨登場」，再次確立了信息安全領域的新標準。

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

最大化兼容性

因爲 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）；
• 明確禁止在記錄協議裏使用壓縮；
• 廢除了 RC四、DES 對稱加密算法；
• 廢除了 ECB、CBC 等傳統分組模式；
• 廢除了 MD五、SHA一、SHA-224 摘要算法；
• 廢除了 RSA、DH 密鑰交換算法和許多命名曲線。

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

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

算法精簡後帶來了一個意料之中的好處：原來衆多的算法、參數組合致使密碼套件很是複雜，難以選擇，而如今的 TLS1.3 裏只有 5 個套件，不管是客戶端仍是服務器都不會再犯「選擇困難症」了。

提高性能

HTTPS 創建鏈接時除了要作 TCP 握手，還要作 TLS 握手，可能致使幾十毫秒甚至上百毫秒的延遲，在移動網絡中延遲還會更嚴重。

如今由於密碼套件大幅度簡化，也就沒有必要再像之前那樣走複雜的協商流程了。TLS1.3 壓縮了之前的「Hello」協商過程，刪除了「Key Exchange」消息，效率提升了一倍。

那麼它是怎麼作的呢？

其實具體的作法仍是利用了擴展。客戶端在「Client Hello」消息裏直接用「supported_groups」帶上支持的曲線，好比 P-25六、x25519，用「key_share」帶上曲線對應的客戶端公鑰參數，用「signature_algorithms」帶上簽名算法。

1.3握手圖

握手分析

小結

1. 爲了兼容 1.一、1.2 等「老」協議，TLS1.3 會「假裝」成 TLS1.2，新特性在「擴展」裏實現；
2. 1.一、1.2 在實踐中發現了不少安全隱患，因此 TLS1.3 大幅度刪減了加密算法，只保留了 ECDHE、AES、ChaCha20、SHA-2 等極少數算法，強化了安全；
3. TLS1.3 也簡化了握手過程，徹底握手只須要一個消息往返，提高了性能。