プードル – SSL セキュリティ脅威の調査

プードル 綿菓子のような脚を持つ犬の品種です。賢いのでドッグショーの常連です。最も人懐っこい犬であっても、噛みつく傾向があります。今では、あらゆる種類のセキュリティ警告が表示され、ハートブリードやシェルショックなどの危険な警告が表示されます。さらに最新作はPOODLEです。

これはすべて、Google のチームが という名前の攻撃を開発し、テストしたときに始まりました。 プードル (Padding Oracle On Downgraded Legacy Encryption) は、Secure Sockets Layer (SSL) バージョン 3 プロトコル、つまり SSLv3 の脆弱性を発見しました。

SSLv3 は廃止されましたが、古い Web ブラウザーと新しい Web ブラウザーの両方で依然として暗号化が使用されています。 (SSLv3 は 18 年前のプロトコルであり、TLS プロトコルに置き換えられました)

POODLE は、Web ブラウザとサーバー間の接続を強制的に SSLv3 にダウングレードしようとします。 POODLE 攻撃は、SSL/TLS に組み込まれているプロトコル バージョン ネゴシエーション機能を利用して SSL 3.0 の使用を強制し、この新しい脆弱性を利用して SSL セッション内の選択されたコンテンツを復号化します。復号化はバイトごとに行われ、クライアントとサーバーの間に大量の接続が生成されます。

どうやってやっているの?

攻撃者は Web サイト上で JavaScript エージェントを実行し、被害者のブラウザに HTTPS リクエストを含む Cookie を送信させることができます。 https://xyz.com、xyz.com が変更されたレコードを受け入れる可能性が無視できない形で、ブラウザによって送信された SSL レコードを傍受して変更します。変更されたレコードが受け入れられた場合、攻撃者は Cookie の 1 バイトを復号化できます。クッキー

TLS 1.0 以降のバージョンでは、復号化されたデータのより堅牢な検証が実行されるため、同じ問題の影響を受けにくくなります。しかし、SSLv3 の場合は修正がありません。

これはどれほど悪いことですか? これはあなたにどのような影響を与えますか?

安全な接続は主に TLS (SSL の後継) を使用します。TLS セッションのネゴシエーションに問題がある場合、Web ブラウザとサーバーは SSLv3 にダウングレードされるため、ほとんどのユーザーは脆弱になります。ほとんどの SSL/TLS 実装は、スムーズなユーザー エクスペリエンスを目的として、レガシー システムと相互運用できるように、SSL 3.0 との下位互換性を維持しています。中間者攻撃を実行する攻撃者は、SSLv3 へのプロトコルのダウングレードをトリガーし、この脆弱性を悪用して、暗号化された通信のサブセットを復号し、そこから情報を抽出する可能性があります。 POODLE の脆弱性は、クライアントのブラウザとサーバーの接続が両方とも SSLv3 をサポートしている場合にのみ機能します。

ブラウザに脆弱性があるかどうかをテストするにはどうすればよいですか?

これをテストするには、poodletest.com Web サイトにアクセスしてください。プードルを見たら危険にさらされます。スプリングフィールド・テリアを見たら、あなたは安全です。

http://www.bolet.org/TestSSLServer/
http://code.google.com/p/sslaudit/

これを防ぐにはどうすればよいでしょうか?プードルのワクチン?

エンド ユーザーは、Web ブラウザで SSLv3 サポートを無効にします。無効になっている場合、POODLE はブラウザをそれにダウングレードできません。セキュリティのベスト プラクティスを推進するために、TLS の最新バージョンを使用することを強くお勧めします。ほとんどのブラウザでは、これは TLS 1.2 である必要があります。

これは私のブラウジング体験に影響しますか?

これは一部の古いブラウザに影響を与えます。 SSLv3 のサポートがすでに終了している Web サイトは、古いブラウザやオペレーティング システムと互換性がなくなります。 Windows XP またはそれ以前のバージョンで実行されている Internet Explorer 6 などの古いブラウザでは、SSL 接続エラーが発生します。

SSL v3 多くの Web ブラウザの将来のリリースでは、デフォルトで無効になる予定です。

これをサーバーで無効にするにはどうすればよいですか?

CloudFlareは、サーバーのSSLv3をデフォルトで無効にすると発表した。多くのサービスプロバイダーも同様でした。

Apache を実行している場合は、他の SSL ディレクティブの中で設定に次の変更を加えるだけです。

SSLプロトコル すべて -SSLv2 -SSLv3

これにより、SSL プロトコル バージョン 2 および 3 が無効になります。

開発者はどうすればこれを防ぐことができるでしょうか?

。ネット

TLS を有効にするには、SecurityProtocol プロパティを使用します。

SecurityProtocol プロパティの使用方法の詳細については、次を参照してください。

http://msdn.microsoft.com/en-us/library/system.net.servicepointmanager.securityprotocol(v=vs.110).as…

http://msdn.microsoft.com/en-us/library/system.net.securityprotocoltype(v=vs.110).aspx

たとえば、C# .NET 実装で TLS 1.2 を強制するには、次のように使用します。

System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12;

ジャワ

注: TLS 1.2 は最初に JDK 7 でサポートされ、JDK 8 ではデフォルトになります: https://blogs.oracle.com/java-platform-group/entry/java_8_will_use_tls

TLS を有効にするには、SSLContext.getInstance メソッドを使用します。

SSLContext.getInstance メソッドの使用方法の詳細については、以下を参照してください。

http://docs.oracle.com/javase/7/docs/api/javax/net/ssl/SSLContext.html#getInstance(java.lang.String)

http://docs.oracle.com/javase/7/docs/api/javax/net/ssl/SSLContext.html#getInstance(java.lang.String,…

http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#SSLContext

たとえば、デフォルトのセキュリティ層プロバイダーを使用して TLS を有効にするには、次のように使用します。

オブジェクト = SSLContext.getInstance(“TLS”);

Sun の Java Secure Socket Extension (JSSE) の使用中に TLS 1.2 を強制するには、次のようにします。

オブジェクト = SSLConnect.getInstance(“TLSv1.2”, “SunJSEE”);

カール

TLS を有効にするには、CURLOPT_SSLVERSION オプションを使用します。

CURLOPT_SSLVERSION オプションの使用方法の詳細については、次のサイトを参照してください。

http://curl.haxx.se/libcurl/c/CURLOPT_SSLVERSION.html

たとえば、cURL で TLS 1.0 以降を使用するようにするには、次のようにします。

C/C++/C#:

curl_easy_setopt(curl, CURLOPT_SSLVERSION, CURL_SSLVERSION_TLSv1);

PHP:

curl_setopt($curl_request、CURLOPT_SSLVERSION、CURL_SSLVERSION_TLSv1);

cURL 7.34.0 以降で TLS 1.2 を強制するには、次を使用します。

C/C++/C#:

curl_easy_setopt(curl, CURLOPT_SSLVERSION, CURL_SSLVERSION_TLSv1_2);

PHP:

curl_setopt($curl_request, CURLOPT_SSLVERSION, CURL_SSLVERSION_TLSv1_2);

レールカーマ チームは、この脆弱性によって生じた穴をすべてふさぐために、完全防御モードで準備を整えました。安全でない SSL/TLS オプションを無効にするために、必要なパッチをアプリケーションに適用しました。

参考文献

http://community.developer.authorize.net/t5/The-Authorize-Net-Developer-Blog/Important-POODLE-Information-Updated/ba-p/48163

http://arstechnica.com/security/2014/10/ssl-broken-again-in-poodle-attack/

https://zmap.io/sslv3/

https://www.imperialviolet.org/2014/10/14/poodle.html

http://blog.cryptographyengineering.com/2014/10/attack-of-week-poodle.html

https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0/

http://www.theregister.co.uk/2014/10/16/poodle_analysis/

http://www.theregister.co.uk/2014/10/14/google_drops_ssl_30_poodle_vulnerability/

http://www.pcworld.com/article/2834015/security-experts-warn-of-poodle-attack-against-ssl-30.html

http://www.alertlogic.com/blog/poodle-man-middle-attack-sslv3/

https://www.us-cert.gov/ncas/alerts/TA14-290A

https://www.openssl.org/~bodo/ssl-poodle.pdf

http://www.makeuseof.com/tag/stop-poodle-from-biting-your-browser/

https://community.qualys.com/blogs/securitylabs/2014/10/15/ssl-3-is-dead-killed-by-the-poodle-attack

プードルを無効にする

https://www.linode.com/docs/security/security-patches/disabling-sslv3-for-poodle

http://askubuntu.com/questions/537196/how-do-i-patch-workaround-sslv3-poodle-vulnerability-cve-2014-3566

ご連絡ください。

最新のアップデートを購読する

関連記事

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

jaJapanese