「クロスプロトコル攻撃が可能となるSSLv2の脆弱性「DROWN」」記事へのコメント

述べられている危険性がDROWN以前の問題のような

[minet (45149)]

TLSをサポートするサーバーとクライアントとの間では、SSLv2が有効になっていても実際の通信に使われることはないため、サーバーによるSSLv2のサポートはセキュリティーリスクとみなされていなかった。

の一文にビックリ。
要求されさえすればいつでも脆弱なプロトコルで応えるようになっていることが、なぜリスクにならないと考えられるのか…。
世のサーバー管理者のセキュリティ意識ってそんなものなの…違うよね？
SSLv2のリスクが小さい（許容できる）と見ていたとしても、それは「有効になっていても通信に使われることはないため」が理由じゃないよね？
ってかこれはDROWN以前のセキュリティ一般論だよね？

秘密鍵を共有する他のサーバーでSSLv2を有効化して

Re:

[Anonymous Coward]

TLSをサポートするサーバーとクライアントとの間では、SSLv2が有効になっていても実際の通信に使われることはないため、サーバーによるSSLv2のサポートはセキュリティーリスクとみなされていなかった。

この記述は The DROWN Attack [drownattack.com]の元ページからの引用です。
（タレコミが引用であることを明示していないのは良くないと思います）

一見おかしな記述のようですが、そうではありません。

このDROWN攻撃を利用すると、SSLv2によるパディングオラクル攻撃により、TLSで行っている通信を解読できます。
そのため、クライアントがTLSで通信しても、サーバがSSLv2をサポートしていると、通信を解読されてしまうことになります。

従来は、クライアントがTLSをサポートしている状況であれば、サーバのSSLv2サポートはセキュリティリスクではないと考えられていたが、実はそうではなかったということです。

元論文によれば、

In ord

Re:

[minet (45149)]

なるほど、「サーバーでのSSLv2サポートはTLSのみサポートするクライアントにとっても脅威」という意味での言い回しだったんですね。
表現はヘンテコだけどまあ理解できました。

Re:述べられている危険性がDROWN以前の問題のような

[njt (4968)]

有効化/無効化という表現だとconfファイルでの設定時と読まれる可能性が高いのに（自分もそう読みました）、configure時 (コンパイル時) の意味で書いてるのが、元記事の文章力不足と思いました。