有關新的信息 (CVE-2020-1968) 在 TLS 協定中，代號為
並在極少數情況下允許確定初步主金鑰 (pre-master)，該主金鑰可用於在攔截傳輸流量 (MITM) 時解密 TLS 連接，包括 HTTPS。 值得注意的是，這種攻擊在實際實施上非常困難，而且更多的是理論性質。 要進行攻擊，需要 TLS 伺服器的特定配置以及非常準確地測量伺服器處理時間的能力。
此問題直接存在於 TLS 規格中，並且僅影響使用基於 DH 金鑰交換協定（Diffie-Hellman，TLS_DH_*”）的密碼的連線。 使用 ECDH 密碼就不會出現這個問題，而且它們仍然安全。 只有 1.2 版及以下版本的 TLS 協定容易受到攻擊；TLS 1.3 不受此問題的影響。 該漏洞發生在跨不同 TLS 連線重用 DH 金鑰的 TLS 實作中（這種行為發生在大約 4.4% 的 Alexa Top 1M 伺服器上）。
在 OpenSSL 1.0.2e 及更早版本中，除非明確設定 SSL_OP_SINGLE_DH_USE 選項，否則在所有伺服器連線中都會重複使用 DH 主鍵。 自 OpenSSL 1.0.2f 起，僅在使用靜態 DH 密碼（“DH-*”，例如“DH-RSA-AES256-SHA”）時重複使用 DH 主金鑰。 此漏洞不會出現在 OpenSSL 1.1.1 中，因為該分支不使用 DH 主金鑰，也不使用靜態 DH 密碼。
當使用DH 金鑰交換方法時，連線雙方都會產生隨機私鑰（以下稱為金鑰「a」和金鑰「b」），並根據該私鑰計算並發送公鑰（ga mod p 和gb mod p）。 各方收到公鑰後，計算出公有主金鑰（gab mod p），用於產生會話金鑰。 Raccoon 攻擊可讓您透過旁道分析來確定主鍵，這是基於以下事實：直到版本 1.2 的 TLS 規範都要求在涉及主鍵的計算之前丟棄主鍵的所有前導空位元組。
包括將截斷的主鍵傳遞給會話金鑰產生函數，該函數基於處理不同資料時具有不同延遲的雜湊函數。 準確測量伺服器執行關鍵操作的時間可以讓攻擊者確定線索（oracle），從而可以判斷主鍵是否從頭開始。 例如，攻擊者可以攔截客戶端發送的公鑰（ga），將其重新傳輸到伺服器並確定
產生的主鍵是否從零開始。
就其本身而言，定義一個位元組的金鑰不會給出任何東西，但是透過攔截客戶端在連接協商期間傳輸的“ga”值，攻擊者可以產生一組與“ga”相關的其他值並將它們傳送到伺服器在單獨的連線協商會話中。 透過產生並發送「gri*ga」值，攻擊者可以透過分析伺服器回應延遲的變化，確定導致接收從零開始的主鍵的值。 確定這些值後，攻擊者可以建立一組方程 並計算原始主鍵。
OpenSSL 漏洞 危險等級較低，且修復已減少為將版本 1.0.2w 中有問題的密碼「TLS_DH_*」移至保護等級不足的密碼類別（「weak-ssl-ciphers」），預設會停用該密碼。 Mozilla 開發者也做了同樣的事情， 在 Firefox 中使用的 NSS 庫中，有 DH 和 DHE 密碼套件。 從 Firefox 78 開始，有問題的密碼被停用。 Chrome 對 DH 的支援早在 2016 年就停止了。 BearSSL、BoringSSL、Botan、Mbed TLS 和 s2n 庫不受此問題的影響，因為它們不支援 DH 密碼或 DH 密碼的靜態變體。
其他問題則單獨註明（）在 F5 BIG-IP 設備的 TLS 堆疊中，使攻擊更真實。 特別是，已經識別出主鍵開頭存在零位元組時設備行為的偏差，可以使用它來代替測量計算的確切延遲。
來源： opennet.ru