新作に関する情報 TLS プロトコルの (CVE-2020-1968)、コードネーム
また、まれな状況では、トランジット トラフィック (MITM) を傍受するときに、HTTPS を含む TLS 接続を復号化するために使用できる予備の主キー (プレマスター) を決定することができます。 この攻撃は実際の実装が非常に難しく、理論的な性質のものであることに注意してください。 攻撃を実行するには、TLS サーバーの特定の構成と、サーバーの処理時間を非常に正確に測定する機能が必要です。
この問題は TLS 仕様に直接存在しており、DH キー交換プロトコル (Diffie-Hellman、TLS_DH_*) に基づく暗号を使用した接続にのみ影響します。 ECDH 暗号では問題は発生せず、安全性が保たれます。 バージョン 1.2 までの TLS プロトコルのみが脆弱であり、TLS 1.3 はこの問題の影響を受けません。 この脆弱性は、異なる TLS 接続間で DH 秘密キーを再利用する TLS 実装で発生します (この動作は、Alexa Top 4.4M サーバーの約 1% で発生します)。
OpenSSL 1.0.2e 以前のリリースでは、SSL_OP_SINGLE_DH_USE オプションが明示的に設定されていない限り、DH 主キーはすべてのサーバー接続で再利用されます。 OpenSSL 1.0.2f 以降、DH 主キーは静的 DH 暗号 (「DH-*」、例: 「DH-RSA-AES256-SHA」) を使用する場合にのみ再利用されます。 OpenSSL 1.1.1 では、このブランチでは DH 主キーも静的 DH 暗号も使用されないため、この脆弱性は発生しません。
DH キー交換方式を使用する場合、接続の両側でランダムな秘密キー (以下、キー「a」およびキー「b」) が生成され、それに基づいて公開キー (ga mod p および gb mod p) が計算されて送信されます。 各当事者が公開キーを受け取った後、共通の主キー (gab mod p) が計算され、セッション キーの生成に使用されます。 Raccoon 攻撃では、バージョン 1.2 までの TLS 仕様では、主キーを含む計算の前に主キーの先頭のすべての null バイトを破棄することが要求されているという事実に基づいて、サイドチャネル分析を通じて主キーを特定できます。
切り捨てられた主キーを含むセッション キー生成関数は、異なるデータを処理するときに異なる遅延を持つハッシュ関数に基づいています。 攻撃者は、サーバーによるキー操作のタイミングを正確に計測することで、主キーがゼロから開始されたかどうかを判断できる手がかり（オラクル）を得ることができます。 たとえば、攻撃者はクライアントから送信された公開キー (ga) を傍受し、それをサーバーに再送信して、
結果の主キーがゼロから始まるかどうか。
キーの XNUMX バイトを定義するだけでは何も得られませんが、接続ネゴシエーション中にクライアントによって送信された「ga」値を傍受することで、攻撃者は「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 スタックに組み込まれており、攻撃がより現実的になります。 特に、主キーの先頭にゼロバイトが存在する場合のデバイスの動作の逸脱が特定されており、これは計算の正確な遅延を測定する代わりに使用できます。
出所： オープンネット.ru