我們用第 11 章討論的兩個主要安全概念來評估 TLS 1.3 的強項：鑑別與前向保密。
鑑別#
TLS 1.3 握手期間，伺服器透過憑證機制向客戶端鑑別自己。
但客戶端並未被鑑別。
客戶端通常這樣向伺服器端應用（例如 Gmail）鑑別自己：
- 在握手完成後，於一則 TLS 記錄中提供使用者名稱與密碼。
- 若客戶端已與遠端服務建立過工作階段，則可送出一個安全 cookie 來鑑別——那種只能透過 TLS 連線傳送的 cookie。
客戶端憑證#
在某些情況下，客戶端可以用與伺服器相似的憑證機制向伺服器鑑別：客戶端送出一份客戶端憑證給伺服器，伺服器驗證後才授權該客戶端。
然而客戶端憑證很少被使用，因為它讓客戶端與伺服器（也就是憑證簽發者）雙方都變得麻煩：
- 客戶端需要執行複雜的操作，才能把憑證整合進自己的系統並保護其私鑰。
- 簽發者需要確保只有經授權的客戶端才收到憑證，還有其他種種要求。
前向保密#
回想第 11 章：若當前工作階段被攻破時先前的工作階段不會被危及，我們就說該金鑰協商提供前向保密。
- 資料外洩模型：只有暫時秘密被攻破。
- 入侵模型：長期秘密被曝光。
所幸 TLS 1.3 的前向保密在資料外洩與入侵這兩種情況下都站得住腳。
資料外洩模型#
攻擊者還原特定工作階段的暫時秘密——工作階段金鑰或 Diffie–Hellman 私鑰（也就是握手流程中的 c、s、secret 與 keys）。
但他們只能用這些值解密當前工作階段的通訊，無法解密先前的工作階段——因為先前用的是不同的
c與s，因而產生不同的金鑰。
入侵模型#
攻擊者還原了長期秘密——也就是憑證中公鑰所對應的私鑰。
然而，這在解密先前工作階段時並不比暫時秘密更有用——因為這把私鑰只用來鑑別伺服器，前向保密因此再度成立。
但實務上呢#
假設攻擊者攻陷了客戶端的機器，取得其全部記憶體的存取權。攻擊者可以從記憶體中還原客戶端當前工作階段的 TLS 工作階段金鑰與秘密。
但更重要的是：若先前的金鑰仍留在記憶體中，攻擊者可能也會找到它們，用來解密先前的工作階段——從而繞過理論上的前向保密。
因此，TLS 實作要確保前向保密，就必須在金鑰不再使用時把它們從記憶體中妥善抹除——通常是把該區記憶體歸零。