TLS 重新協商與恢復
請解釋TLS重新協商和恢復之間的區別。
我的理解如下：在 TLS 1.2 的上下文中，重新協商和恢復看起來是一樣的，但是前者可以從伺服器/客戶端的 HelloRequest/ClientHello 開始，而後者可以從客戶端的 ClientHello 開始. 在這兩種情況下，都會發生客戶端-伺服器對話，然後是簡短的握手**（或不發生？）**，安全參數不會改變，並且使用帶有新隨機數的“舊”預主密鑰重新計算新的密鑰材料。
從記錄層的角度來看，所有重新協商/恢復消息都應該使用“目前記錄狀態”進行處理——這意味著它們是使用“目前”密鑰加密/驗證的。
重新協商可能發生在現有會話的中間，不需要“會話票證”或“會話 ID”來查找“目前狀態參數”，只需 5 個元組即可用於查找正確執行的會話上下文。（是真的嗎？）
此外，即使在實際連接已關閉**（是真的嗎？）**之後，恢復也可能發生，我們需要 sessionTicket 或 sessionId 來查找安全參數並進行解密，但是 ClientHello 消息本身是加密的。 這是如何解決 TLS1.2 的？
在 TLS1.3 的上下文中，重新協商是使用 KeyUpdate 消息完成的，並且在草案中有明確的描述，但恢復也有同樣的問題。 如何解決 TLS1.3 的恢復問題？
重新協商可能發生在現有會話的中間，不需要“會話已標記”或“會話 ID”來查找“目前狀態參數”，只需 5 個元組即可用於查找正確執行的會話上下文。
是的。
$$ … $$但是 ClientHello 消息本身是加密的。這是如何解決 TLS1.2 的？
簡短握手中的 ClientHello 實際上沒有加密。簡短握手的消息流大致如下：客戶端發送未加密的 ClientHello，伺服器響應 ServerHello、ChangeCipherSpec 和 Finished 消息，客戶端響應 ChangeCipherSpec 和 Finished 消息和應用程序數據。另見 RFC 5246 第 37 頁。
在這兩種情況下，客戶端-伺服器對話框都遵循縮寫握手
不，只有在會話恢復時才使用簡短的握手，對於重新協商，會執行完整的握手。
即使在實際連接已關閉後，也可能會發生相反的恢復
是的。
在 TLS1.3 的上下文中，現在使用 KeyUpdate 消息完成重新協商，並在草案中明確描述，但恢復存在相同的問題。TLS1.3 如何解決恢復？
TLS 1.3 草案 (-23) 的第 2.2 節討論了會話恢復協議流程。4.6.1 節詳細討論票證機制的工作原理。第 4.2.11 節討論瞭如何在 Hello Messages 中使用票證。事實證明，客戶端可以在（明文！）ClientHello 中向伺服器提供多個 PSK 身份，伺服器選擇並因此“消費”至多一個，並在其 ServerHello 消息中指示哪個。