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回の対象鍵暗号化操作を行う必要がある）
述べられている危険性がDROWN以前の問題のような (スコア:3, すばらしい洞察)
TLSをサポートするサーバーとクライアントとの間では、SSLv2が有効になっていても実際の通信に使われることはないため、サーバーによるSSLv2のサポートはセキュリティーリスクとみなされていなかった。
の一文にビックリ。
要求されさえすればいつでも脆弱なプロトコルで応えるようになっていることが、なぜリスクにならないと考えられるのか…。
世のサーバー管理者のセキュリティ意識ってそんなものなの…違うよね？
SSLv2のリスクが小さい（許容できる）と見ていたとしても、それは「有効になっていても通信に使われることはないため」が理由じゃないよね？
ってかこれはDROWN以前のセキュリティ一般論だよね？
秘密鍵を共有する他のサーバーでSSLv2を有効化して
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時 (コンパイル時) の意味で書いてるのが、元記事の文章力不足と思いました。
Re: (スコア:0)
元コメントは「そもそもSSLv2を有効なまま放置しているのが問題だ」という意味、つまり「クライアントがTLSをサポートしている状況であれば、サーバのSSLv2サポートはセキュリティリスクではない」という考え方自体に問題があると言っているのです。
おかしな記述云々という意味ではありません。
あなたの言っていることは理解したうえで、そもそもその考え方が間違っていると言っているのです。
Re: (スコア:0)
別人ですが、例えば
webサイトが単一方向の情報発信系で、電子証明書も暗号化目的では無く実在証明だとして、
クライアント側から意図して低いレベルの通信できたあげく、
通信中に内容が改ざんされても、サーバ運営者では無く閲覧者の責任ではありませんか？
非常事態用にHTTP接続でも可能なログイン経路を残した金融機関もありますね。
もちろん利用は自己責任の注意書きで。