記錄協議中的 TLS 完成的消息加密是多餘的嗎？
TLS 完成的消息是在記錄協議的目前密碼狀態下加密的。能夠在記錄協議上對 FINISHED 消息進行身份驗證，證明了對等端點的真實性。驗證 handshake_hash 證明握手沒有被 MITM 篡改。
FINISHED 中的 verify_data 是使用 PRF 和主密鑰計算的。因此，verify_data 的驗證應該足以證明對等方的身份驗證和握手消息的完整性。
為什麼另外記錄協議對 FINISHED 消息進行密碼操作？我認為如果在 change_cipher_spec 之前發送 FINISHED 消息，它可能是等效的。
如果您在設置密碼規範
Finished後必須是第一條消息change_cipher_spec，Finished那麼您將獲得額外的好處，即在傳輸任何（潛在敏感的）使用者數據之前需要成功解密消息。此步驟用作額外的“校驗和”。來自RFC 5246 的第 7.4.9 節：（強調我的）
Finished 消息是第一個使用剛剛協商好的算法、密鑰和秘密保護的消息。 Finished 消息的接收者必須驗證內容是否正確。 一旦一方發送了它的 Finished 消息並從其對等方接收並驗證了 Finished 消息，它就可以開始通過連接發送和接收應用程序數據。
編輯：
您想知道加密
Finished是否是不必要的，因為它verify_data提供了足夠的身份驗證來防止篡改。我聲稱發送未加密的Finished消息對於 TLS 來說將是災難性的。正常 TLS 握手的結束如下所示：
$ \text{client} \rightarrow \text{server}: $
change_cipher_spec$ \text{client} \rightarrow \text{server}: $
Finished$ a_k $$ \text{server} \rightarrow \text{client}: $
change_cipher_spec$ \text{server} \rightarrow \text{client}: $
Finished$ a_k $$ \text{client} \rightarrow \text{server}: $
encrypted application data transmits...$ m_k $這裡， $ a_k $ 和 $ m_k $ 是身份驗證碼
Finished和會話數據，由 $ k $ . 重要的是要重申，在change_cipher_spec收到消息之前，目前的密碼套件不提供加密或身份驗證。在收到change_cipher_spec.現在想像一下網路上的 Andy Adversary 觀察這個握手。在協商密碼套件僅處理身份驗證而不處理加密的特殊情況下，Andy 會刪除
change_cipher_spec消息，因此客戶端和伺服器永遠不會更新其密碼套件，因此永遠不會使用協商參數啟用身份驗證或加密。歡迎來到災難。Finished現在安迪坐在中間，從消息和後來的敏感會話數據中剝離身份驗證欄位。所以現在你也沒有身份驗證。這是修改後的失敗握手：
$ \text{client} \rightarrow \text{adversary}: $
change_cipher_spec$ \text{client} \rightarrow \text{adversary}: $
Finished$ a_k $$ \text{adversary} \rightarrow \text{client}: $
Finished$ a $$ \text{server} \rightarrow \text{adversary}: $
change_cipher_spec$ \text{server} \rightarrow \text{adversary}: $
Finished$ a_k $$ \text{adversary} \rightarrow \text{client}: $
Finished$ a $$ \text{client} \rightarrow \text{adversary}: $
unencrypted application data transmits...$ m_k $$ \text{adversary} \rightarrow \text{server}: $
unencrypted application data transmits...$ m $由於沒有加密，Andy Adversary 很容易剝離 MAC 欄位。因此，現在他不僅可以訪問未加密、未經身份驗證的消息，而且還可以偽造任何他喜歡的消息。
如果正常情況下加密是密碼套件的一部分，則攻擊要困難得多，但關鍵是通過傳入
Finishedafterchange_cipher_spec，您甚至可以消除攻擊的可能性。我在這裡描述的內容直接來自Wagner 和 Schneier，他們在 1997 年就知道了這種攻擊。事實上，他們注意到 Netscape 的 SSL 3 實現很容易受到它的攻擊。閱讀該論文的第 4.3 節了解更多詳細資訊。
他們建議防止此類攻擊？
最簡單的解決方法是要求 SSL 實現在接受完成的消息之前接收更改密碼規範消息。
他們認為這是 SSL 規範中的一個基本缺陷，這當然在 TLS 中得到了糾正：
一些讀者可能會抱怨這個要求應該是顯而易見的，即使 SSL 規範中沒有明確說明。我們不能指責這種清晰的願景。
一般來說，這不是唯一可以通過“校驗和”參數阻止的攻擊，或者 Bellare 和 Rogaway 所說的匹配對話，客戶端和伺服器都在傳輸敏感數據之前驗證加密和身份驗證。另見第 II-1 節。
結論：發送加密
Finished後是保護消息change_cipher_spec的最簡單解決方案。change_cipher_spec