比較 RFC 5246 SessionID 重用與 RFC 5077 會話恢復？
您能幫我理解 RFC 5246 SessionID 重用和 RFC 5077 會話恢復之間的算法和實際差異嗎？
兩者似乎都是在沒有伺服器證書交換的情況下確定第二個 TLS 會話的方法，利用完整的證書交換和對先前的單獨 TLS 會話的驗證。
閱讀了RFC 5246 § 7.4.1.2和RFC 5077 § 3後，似乎 RFC 5077 將令牌交給客戶端，該令牌具有使用伺服器密鑰加密的會話設置資訊，以便客戶端可以將令牌交回伺服器並使用快捷方式會話建立參數的協商和協商。另一方面，RFC 5246 僅提供對雙方共享的現有連接的引用，並允許他們重新使用這些會話參數，基於雙方仍將它們保留在原始會話的記憶體中。
這是正確的理論把握嗎？
就“足夠接近政府工作”而言，我對兩種不同類型連接的實際使用感興趣：
- RFC 5246 SessionID 好嗎
- 只要原始會話仍然處於活動狀態？
- 只要有連續的會話鏈使用相同的 SessionID？
- 在所有此類會話關閉後但在 SessionID 從活動記憶體中刪除之前的一段鬆散定義的時間內？
- 是 RFC 5077 會話恢復
- 常用來代替 RFC 5246 SessionID？
- 通常用於 RFC 5246 的更廣泛分離的連接？
- 一般都用嗎？
- 兩者是否如此處所述不同：
- RFC 5077 令牌創建（伺服器發送到客戶端）完全包含在加密數據包中，例如，在握手之後？
- RFC 5246 會話交換是完全未加密的，例如，在握手的早期（ClientHello、ServerHello）部分？
感謝您分享的任何見解！
更新：以下內容通過 TLS 1.2 有效。2018年的**TLS1.3**從根本上改變這一點；舊的恢復和舊的可選票機制都消失了。相反，兩端都可以選擇儲存（如舊恢復）一個秘密和一些屬性，但這個儲存的秘密現在不是先前會話的主秘密，而是一個“預共享密鑰”（PSK），單向派生自之前的會話，因此儲存的 PSK 的妥協不會危害之前的會話。伺服器使用為 5077 定義的“新票證”消息類型，但現在它只包含一個標識符而不是實際票證。新會話可以直接使用此 PSK 作為“輸入”密鑰，也可以使用 DHE 或 ECDHE 驗證新的密鑰交換，其方式與它可以（和 1. 2 和更低版本已經可以）用於手動配置的 PSK——除了手動 PSK 一直是並且我希望仍然會非常罕見。此外，現在不再進行重新協商——儘管添加了執行客戶端身份驗證和更新工作（對稱）密鑰的特定操作——所以現在會話和連接基本相同。
是的，你有基本的想法。Session-id 資訊在兩端儲存（記憶體）；票證僅儲存在客戶端，由伺服器加密。兩者都重用了“密鑰交換”，在 SSL/TLS 中實際上是密鑰交換與身份驗證相結合；儘管身份驗證可以是雙向的（伺服器和客戶端），因此是證書的“交換”，但它通常是僅限伺服器的。
要清楚細節，您需要區分會話和連接。SSL/TLS會話基本上是完整握手的結果：協商版本、密碼套件和（最重要的）主密鑰，也許還有其他一些位。這個加上 nonces 是正確進行加密和 HMAC 所需的數據，或者在 TLSv1.2 中可選的“認證加密”模式 GCM 或 CCM。連接與 TCP連接相連，並以初始握手開始，以創建和使用新會話，或恢復現有會話。恢復可用於某個視窗內不同時間的連接，或同時用於多個連接——如果不是所有瀏覽器，大多數瀏覽器可能會打開 4 到 10 個並行連接來下載大多數（？）網頁上使用的 10 或 100 資源現在。使用重新協商在一個連接上擁有多個會話也是可能的，但很少見，通常是為了進行不同的身份驗證或對長期連接進行重新加密。（好吧，除非伺服器禁用重新協商作為對正確修復為 rfc 5746 的 MitM 前綴攻擊的笨拙防禦。）
Session-id 自 1996 年 SSLv3 以來一直在基礎協議中；自 2006 年以來，ticket 是一個可選擴展。雖然 session-id 在協議中，但你不必完全實現它——伺服器總是可以返回一個空的 session-id，而客戶端總是可以“忘記”任何 session-id它接收。Ticket 對擁有大量客戶端的伺服器最有用——比如穀歌、雅虎、推特、臉書的數百萬——這將需要保存大量會話並在伺服器“場”中的多台機器上分發/同步它們（可解決的問題，但如果你不需要它會更容易）。
因此，根據您的具體情況：
- 只要兩個端點都選擇保存它並有空間，會話 ID 就很好。通常這最多是幾分鐘到一個小時，但如果兩個端點都支持，它可能會更多。在我看過的實現中，它是每個應用程序可配置的。它會優雅地失敗——如果客戶端丟棄伺服器的會話並發送空的 ClientHello，伺服器只會創建一個新會話並丟棄舊會話（如果仍然保存）；如果客戶端已經（並請求）一個會話伺服器已經丟棄，伺服器強制一個新的，客戶端丟棄它的舊的。
- 當我查看時，我只在一些高容量站點（和我的 OpenSSL 測試平台）上看到了提供的票證（如果客戶提供支持），但我並沒有聲稱已經進行了徹底的調查，而且我沒有看過任何發表的。正如 5077 所描述的，如果您確實使用票證，您實際上會忽略該會話的會話 ID。伺服器允許票證的有效期比它在其（可能有限且擁擠的）記憶體中保留會話 ID 的時間更長當然是有意義的，但我沒有數據。
- 初始握手始終未加密，直到 ChangeCipherSpec 和 Finished，特定元素除外。特別是對於 RSA 密鑰交換，客戶端公鑰將預主密鑰加密到伺服器。（對於 DH* 和 ECDH*，公鑰不需要加密，也不需要加密，但仍會產生秘密協議。）如果使用票證，則由伺服器對其自身進行加密。如果您確實使用了重新協商，那麼整個握手都會（超級）加密，即使它通常不需要加密，從而提供一種（笨拙的）方式來獲得該功能。