為什麼 TLS 容易受到協議降級攻擊？
Ivan Ristić（關於 SSL 的所有事情的非凡專家）最近的一篇部落格文章說：
所有主流瀏覽器都容易受到協議降級攻擊；活躍的 MITM 可以模擬故障情況並強制所有瀏覽器退出嘗試協商 TLS 1.2，使它們一直回退到 SSL 3。此時，可預測的 IV 設計再次成為問題。在協議降級漏洞得到修復之前，較新的協議將僅對被動攻擊者有用，而對主動攻擊者無效。
為什麼是這樣？為什麼 TLS 易受此影響？
我知道 SSL 3 包含特殊的緩解措施，以防止協議降級攻擊，其中中間人降級了兩個支持 SSL3 的端點，因此它們最終使用 SSL 2。SSL 3 中的這種保護至關重要，因為 SSL 2 有一些主要的問題，並且如果您可以將兩個端點都降級到 SSL 2，那麼令人討厭的攻擊將成為可能。令人高興的是，SSL 3 設計者提前預料到了這種風險，並確保在協議中引入一種特殊機制來防止“降級到 SSL2”攻擊。
那麼，為什麼 TLS 最終沒有採取任何緩解措施來防止從 TLS 1.2 降級到 TLS 1.0 甚至 SSL 3.0？為什麼添加降級保護並非易事？TLS 標準委員會是否忽略了這一點？或者，它是否被認為是低優先級？未來版本的 TLS 是否有直接解決此問題的方法？
**簡短的回答：**因為瀏覽器開發人員長期以來一直認為互操作性比安全性和標準合規性更重要。
**稍微長一點的答案：**一些 SSL/TLS 伺服器實現不能正確協商協議版本，但如果客戶端嘗試協商伺服器不支持的協議版本，則會以致命警報終止連接。這可能發生在握手協議的三個步驟中的任何一個：
- 當伺服器解析客戶端 hello 時（應該包含客戶端支持的最高協議版本）。正確實現的伺服器應該儲存客戶端版本值，即使伺服器不支持它。
- 解析包含 RSA 加密的預主密鑰（應包含客戶端支持的最高協議版本作為前兩個八位字節）的客戶端密鑰交換消息時。此版本欄位應與上面的客戶端版本值進行比較，而不是與協商的版本進行比較。
- 驗證客戶端完成消息時（應該是所有握手消息的雜湊，包括客戶端 hello，其中包含客戶端支持的最高協議版本）。
現在，如果伺服器由於某種原因沒有按照 TLS 1.0、1.1 或 1.2 標準處理這些步驟，但是一種或另一種方式，例如要求客戶端支持的最高協議版本具有特定值，或者是不大於伺服器支持的最高協議版本，客戶端有兩種選擇：要麼連接失敗，並顯示給使用者的錯誤消息，要麼嘗試再次連接，禁用最高協議版本。
如果客戶端使用第二種選擇（例如 Chrome 使用，但 IE 10 不使用），則該漏洞是可能的。即使真實伺服器實際上支持 TLS 1.1 或 TLS 1.2並且真實伺服器確實正確處理客戶端版本值，MITM 也可能利用客戶端不知道哪個伺服器正確處理客戶端，並在兩者中註入警報讓客戶端使用較低版本重新連接的說明。
**編輯：**為了完整起見，我應該補充一點，我同意@Thomas 在他的回答中認為這在很大程度上應該不是問題，僅僅是因為：
- 微不足道，即使在利用此行為的 MITM 攻擊下，客戶端和伺服器都無法協商他們未啟用的協議版本，並且
- 客戶端和伺服器都不應該啟用不能提供足夠安全性的協議版本。
根本問題並不是某些客戶端以不受標準嚴格支持的方式協商協議版本，以便能夠連接到可能或可能不會以不受標準嚴格支持的方式協商協議版本的伺服器標準。
相反，問題可能發生在 Carol 可能連接到多個伺服器的情況下，但 TLS 1.2 只需要連接到 Sue，對於所有其他伺服器，SSL 3.0 就足夠了。相反，Sue 可能會接受來自多個客戶端的連接，但只有來自 Carol 的連接需要 TLS 1.2。理想情況下，Carol 和 Sue 應該能夠依靠協議協商來確保自動協商 TLS 1.2（在這種情況下，他們可能會或可能不會受到攻擊），但正確的實現應該真正檢查 TLS協商後，連接滿足最低安全要求。