伺服器未完全驗證 TLS 連接的 Client Finished 數據包中的數據有什麼影響？
F5 BIG-IP 設備存在一個漏洞，在該漏洞中，並非 TLS 連接中已完成數據包的所有字節都經過驗證。可以在此處找到此類技術描述。F5 不認為它是一個漏洞，所以他們不會修補它，而且由於 PCI 合規性的原因，它目前讓我很頭疼。目前，似乎沒有人就是否存在漏洞達成一致，也沒有真正清楚地解釋實際影響和攻擊要求。
我的理解是，TLS 中的客戶端和伺服器完成數據包旨在事後相互驗證握手消息，包括主密鑰交換。我的想法是，如果攻擊者要對 TLS 連接進行中間人操作，他們可以利用此漏洞通過欺騙 Client Finished 數據包來降級連接，甚至可能破壞主密鑰。我不確定該過程將如何從那裡進行，並驗證 cient 上的 Server Finished 數據包。
假設 Finished 數據包中的某些任意數量的字節沒有得到正確驗證，那麼這個漏洞的真正影響是什麼？有了這個錯誤，連接的安全性是否主要依賴於客戶端對 Server Finished 數據包的驗證？
假設伺服器不檢查 Client Finished 值。這意味著 MITM 可能會更改一些握手消息，而伺服器不會知道這一點（例如，降級，正如您所提到的）。因此，您可以使用它來欺騙不檢查 Client Finished 值的伺服器。
如果伺服器檢查 n 位，您有 1/2^n 的機會隨機獲得 Client Finished 值。您可能能夠預測剩餘的客戶端消息，然後使用蠻力離線嘗試不同的隨機握手修改，直到在伺服器將驗證的 n 個位置中生成正確的完成位。這將需要大約 2^n 次嘗試，這對於小 n 是可行的。通過發送此握手序列，您可以欺騙伺服器，使其認為客戶端發送了修改後的握手。
現在，伺服器發回一個 Server Finished 消息，其中包括伺服器看到的所有消息的雜湊值，包括 Client Finished 值。您修改後的握手將完全改變 Server Finished 的雜湊值。結果，除了伺服器檢查的那些位之外，您不得不強制執行客戶端檢查的所有位。如果客戶端是懶惰的並且只檢查 m 位，那麼總體而言您正在查看 2^(n+m) 次嘗試，這可能是可行的。但是，如果客戶端驗證整個伺服器已完成，您將不得不破壞所有 12 個字節或 96 位，這在連接超時之前不容易被暴力破解。
安全性（此處定義為蠻力嘗試讓兩條 Finished 消息進行驗證的次數）大致取決於客戶端和伺服器檢查的總位數，因此如果伺服器不檢查任何位，則安全性依賴於您說，關於客戶端對 Server Finished 消息的驗證。
您提到更改主密鑰。這可以允許 MITM 創建到伺服器的有效連接（例如，如果使用 RSA 密鑰交換）。但是，MITM 不知道客戶端使用的主密鑰，因為需要伺服器私鑰，因此對於 Server Finished 消息，您有確定加密和 MAC 密鑰的問題。如果您與客戶端協商一個弱密碼套件，這可能比暴力強制伺服器完成消息更容易。
根據客戶端和伺服器的配置，其他攻擊可能是可能的，因此最好伺服器完全驗證 Client Hello 以緩解它們。