帶有 AES-GCM 的 TLS 1.2 密碼套件 – 哪些數據（如果有）作為附加身份驗證數據傳遞給 AES-GCM 密碼？

TLS 1.2 定義了許多使用 AES-GCM 的密碼套件，例如：

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256  
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384  
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256    
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384    

由於 AES-GCM 是一種AEAD密碼，因此它同時處理加密和完整性驗證。此外，它可以選擇接受額外的身份驗證數據作為其輸入之一（除了明文、密鑰和 iv）。附加的認證數據沒有加密，但包含在完整性驗證過程中。

我已經閱讀了RFC 5289、RFC 5288、RFC 5246等，但我沒有發現任何關於哪些數據（如果有）作為 TLS 1.2 實現中的附加身份驗證數據傳遞給 AES-GCM 密碼的資訊，例如作為上述之一。

我的問題是：在使用 AES-GCM 的 TLS 1.2 實現中——哪些數據（如果有）作為附加身份驗證數據傳遞給 AES-GCM 密碼？

實際上RFC 5246 的第 6.2.3.3 節討論了相關數據：

額外的認證數據，我們表示為

additional_data，定義如下：

additional_data = seq_num + TLSCompressed.type +
                    TLSCompressed.version + TLSCompressed.length;

其中“+”表示串聯。

因此，序列號、數據包版本、數據包類型和數據包長度作為關聯數據傳遞給密碼。

---

那麼為什麼這些數據要經過身份驗證呢？

• 序列號：對此進行身份驗證有助於防止重新排序和重放攻擊，並將序列號綁定到數據包。
• 協議版本：對此進行身份驗證可確保如果您無法降級協議版本（例如到 SSLv3）以利用弱點並了解有關目前數據包內容的資訊。
• 數據包類型：我想這會阻止您將握手數據包重新用於應用程序流量數據包（可能具有獨立的序列號流）
• 數據包長度：這會阻止您在某處默默地截斷一些數據，但主要是在這裡，因為它是公共數據並且對其進行身份驗證並沒有真正的傷害。

引用自：https://crypto.stackexchange.com/questions/59697