クロスプロトコル攻撃が可能となるSSLv2の脆弱性「DROWN」 21
古い規格は積極的にオフにしましょう 部門より
クロスプロトコル攻撃が可能となるSSLv2の脆弱性「DROWN （Decrypting RSA with Obsolete and Weakened eNcryption）」の詳細が公表された（The DROWN Attack、OpenSSL Blog、Red Hat Security Blog、JVNVU#90617353）。
SSLv2の安全性が低いことは知られているが、多くのサーバーでSSLv2のサポートが有効になっている。TLSをサポートするサーバーとクライアントとの間では、SSLv2が有効になっていても実際の通信に使われることはないため、サーバーによるSSLv2のサポートはセキュリティーリスクとみなされていなかった。
DROWNではサーバーとクライアントがTLSで通信していても、攻撃者はSSLv2接続でパディングオラクル攻撃を仕掛けて暗号を解読できる。サーバーがSSLv2を有効化している場合のほか、クライアントが接続しているサーバーでSSLv2を有効化していなくても、秘密鍵を共有する他のサーバーでSSLv2を有効化している場合にはDROWNの影響を受ける。たとえば、SSLv2がメールサーバーで有効になっていて、SSLv2を無効にしたWebサーバーと秘密鍵を共有している場合、メールサーバーにパディングオラクル攻撃を行い、Webサーバーでの暗号化された通信を解読できる。
The DROWN Attackによると、HTTPSサーバー全体のうち17%がSSLv2を有効化しており、16%がSSLv2を有効にした他のサーバーと公開鍵を共有している。合計するとDROWNの影響を受けるHTTPSサーバーは全体の33%となり、上位100万ドメインでも25%に上るという。
サーバー管理者はSSLv2を無効化することでDROWNに対処できる。ただし、SSLv2の無効化はサーバーソフトウェアによって複雑な処理が必要なこともある。OpenSSLの場合は、簡単な対処方法として最新版への更新が推奨されている。IISではバージョン7.0以降、NSSではバージョン3.13以降で、SSLv2がデフォルトで無効となっている。これらのソフトウェアを使用している場合でも、The DROWN Attackが提供している脆弱性チェックツールでの確認が推奨される。
DROWNはサーバー側での対処が必要であり、クライアント側では特にできることはない。利用するWebサイトがDROWNの影響を受けるかどうか、上述の脆弱性チェックツールで確認しておくといいだろう。The DROWN AttackではAlexaトップ10,000サイトで脆弱性のあるドメインをリストアップしているが、リストには日本のWebサイトも多数含まれている。
述べられている危険性がDROWN以前の問題のような (スコア:3, すばらしい洞察)
TLSをサポートするサーバーとクライアントとの間では、SSLv2が有効になっていても実際の通信に使われることはないため、サーバーによるSSLv2のサポートはセキュリティーリスクとみなされていなかった。
の一文にビックリ。
要求されさえすればいつでも脆弱なプロトコルで応えるようになっていることが、なぜリスクにならないと考えられるのか…。
世のサーバー管理者のセキュリティ意識ってそんなものなの…違うよね？
SSLv2のリスクが小さい（許容できる）と見ていたとしても、それは「有効になっていても通信に使われることはないため」が理由じゃないよね？
ってかこれはDROWN以前のセキュリティ一般論だよね？
秘密鍵を共有する他のサーバーでSSLv2を有効化している場合にはDROWNの影響を受ける。
鍵が共有ならセキュリティの強度は一番脆い所で決定される、これもDROWNに限らないセキュリティ一般論だと思うのだけど、何でこのコンテキストで述べられているのだろう？
以前にSSLの脆弱性が明らかにあった時にWebサーバー以外がアウトオブ眼中の管理者が多かった、ってこと？
何か、DROWN脆弱性そのものとは異なるレイヤレベルの危険性ばかり述べられている印象を受けるんだけど。
DROWNが危険っていうんじゃなくて、危険なSSL運用が多いよ、って感じ。
セキュリティ啓発の一種、なのか？
Re:述べられている危険性がDROWN以前の問題のような (スコア:1)
TLSをサポートするサーバーとクライアントとの間では、SSLv2が有効になっていても実際の通信に使われることはないため、サーバーによるSSLv2のサポートはセキュリティーリスクとみなされていなかった。
この記述はThe DROWN Attack [drownattack.com]の元ページからの引用です。
（タレコミが引用であることを明示していないのは良くないと思います）
一見おかしな記述のようですが、そうではありません。
このDROWN攻撃を利用すると、SSLv2によるパディングオラクル攻撃により、TLSで行っている通信を解読できます。
そのため、クライアントがTLSで通信しても、サーバがSSLv2をサポートしていると、通信を解読されてしまうことになります。
従来は、クライアントがTLSをサポートしている状況であれば、サーバのSSLv2サポートはセキュリティリスクではないと考えられていたが、実はそうではなかったということです。
元論文によれば、
In order to decrypt one TLS session, the attacker must passively capture about 1,000 TLS sessions using RSA key exchange, make 40,000 SSLv2 connections to the victim server and perform 250 symmetric encryption operations.
（攻撃者は、1つのTLSセッションを解読するのに、約1,000回のTLSセッションをキャプチャーし、標的サーバに対して40,000回のSSLv2接続を行い、さらに250回の対象鍵暗号化操作を行う必要がある）
とのことです。
Re:述べられている危険性がDROWN以前の問題のような (スコア:1)
なるほど、「サーバーでのSSLv2サポートはTLSのみサポートするクライアントにとっても脅威」という意味での言い回しだったんですね。
表現はヘンテコだけどまあ理解できました。
Re:述べられている危険性がDROWN以前の問題のような (スコア:1)
有効化/無効化という表現だとconfファイルでの設定時と読まれる可能性が高いのに（自分もそう読みました）、configure時 (コンパイル時) の意味で書いてるのが、元記事の文章力不足と思いました。