SSL/TLS 協議運行機制概述（二）

2020 年 3 月 15 日
筆記

SSL/TLS 協議運行機制概述（二）

在SSL/TLS 協議運行機制概述（一）中介紹了TLS 1.2 的運行機制，現在我們來看年 TLS 1.3 的運行機制。會涉及到SSL/TLS 協議運行機制概述（一）中的一些概念，有需要的可以配合著看。

TLS 1.3 握手過程

與 TLS 1.2 握手一樣，"Client Hello" 消息啟動握手，但這次它包含了很多資訊。TLS 1.3 將支援的密碼套件從37個減少到5個。在握手的上下文中，這意味著客戶端除了從它猜測的任何協議發送密鑰共享外，還可以猜測將使用什麼密鑰協議/交換協議。
伺服器將用自己的 "Server Hello" 消息響應。就像1.2握手一樣，它也會在此時發送證書。並且，如果客戶機猜對了，並且兩端同意相同的 AEAD 協議，伺服器將發送自己的密鑰共享部分，計算會話密鑰(session key)，並以 "Server Finished" 消息結束。
現在客戶端已經擁有了所有相關資訊，客戶端將對 SSL 證書進行身份驗證，並使用這兩個密鑰共享來計算它自己的會話密鑰副本。完成後，它會發送自己的完成消息。

TLS 1.3 握手相對 TLS 1.2 的改進

1.更少的往返次數

最理想的情況是，TLS 1.2握手可以進行兩次往返。在某些情況下，可能需要額外的往返行程，因此我們是在最佳情況下所討論的往返行程的數量。對比如下兩個圖：

TLS 1.2 握手

TLS 1.3 握手

相比之下，TLS 1.3 的握手只是一次往返旅行

2.簡化密碼套件

TLS 1.2 支援的密碼套件有37個，到目前為止有些已經很不安全了，而且過多的配置會導致過分的複雜，因此 TLS 1.3 將支援的密碼套件從37個減少到5個。往返次數的減少歸結於密碼套件支援的減少。
最值得注意的是，關於密鑰交換的整個選擇都被刪除了。Diffie-Hellman Ephemeral 方案是TLS 1.3 的唯一選擇，它允許客戶端在握手的第一部分將其密鑰共享資訊與 Client Hello 一起發送。RSA 加密與所有其他靜態密鑰交換方案一起被完全刪除。完美前向保密(PFS)已經成為 TLS 1.3 的一項要求。

3.零往返恢復(0-RTT)

TLS握手在歷史上一直很昂貴：增加伺服器的負載和增加連接的延遲。所以縮小它的想法很有吸引力。0-RTT 只是通過存儲一些有關客戶端的秘密資訊來實現這一點，通常是會話 ID (Session ID) 或會話票證(Session Tickets)，以便將來雙方連接時使用。

儘管0-RTT帶來了所有好處，但它實際上也帶來了一些潛在的問題。
（1）它使客戶端容易受到重播攻擊。在重播攻擊中，以某種方式設法訪問加密會話的攻擊者可以獲取 0-RTT 數據（包括客戶端的第一個請求），並將其再次發送到伺服器，它可以欺騙伺服器，因為它無法知道數據來自哪裡。如果攻擊者多次發送這個請求，就稱為「重放攻擊」。當然，它並不像聽起來那麼容易，有一些機制可以阻止這種攻擊。

（2）更大的問題是，0-RTT 握手可能通過提供解密舊會話的途徑破壞完美前向保密(PFS)。當然，通過定期輪換會話密鑰可以輕鬆避免這種情況。

4.保護更多的 TLS 1.3 握手

在握手的早期，最大的擔心之一是它的明文發送量。在 TLS 1.2 握手中，握手的協商階段是不安全的，而是使用一個簡單的 MAC 來確保沒有人篡改傳輸的內容。TLS 1.3 握手對早期部分進行了數字簽名(對 ServerHello 消息之後的握手資訊加密)，這使得握手更安全，減少了降級攻擊，並且通過擴展它們促進了許多攻擊。這還提供了一種途徑，通過驗證私鑰的擁有情況來更快速有效地對伺服器進行身份驗證。

參考鏈接：

https://www.thesslstore.com/blog/explaining-ssl-handshake/
https://tools.ietf.org/html/draft-ietf-tls-tls13-18#section-4