クロスプロトコル攻撃が可能となる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時 (コンパイル時) の意味で書いてるのが、元記事の文章力不足と思いました。
Re: (スコア:0)
元コメントは「そもそもSSLv2を有効なまま放置しているのが問題だ」という意味、つまり「クライアントがTLSをサポートしている状況であれば、サーバのSSLv2サポートはセキュリティリスクではない」という考え方自体に問題があると言っているのです。
おかしな記述云々という意味ではありません。
あなたの言っていることは理解したうえで、そもそもその考え方が間違っていると言っているのです。
Re: (スコア:0)
別人ですが、例えば
webサイトが単一方向の情報発信系で、電子証明書も暗号化目的では無く実在証明だとして、
クライアント側から意図して低いレベルの通信できたあげく、
通信中に内容が改ざんされても、サーバ運営者では無く閲覧者の責任ではありませんか？
非常事態用にHTTP接続でも可能なログイン経路を残した金融機関もありますね。
もちろん利用は自己責任の注意書きで。
Re: (スコア:0)
XPの既定はSSLv3までだよ。息を吐くように嘘つくな。
Re:述べられている危険性がDROWN以前の問題のような (スコア:1)
あとガラケーも。今どきSSLv2を有効にする必要などまったくないと断言して差し支えない。
Re:述べられている危険性がDROWN以前の問題のような (スコア:1)
> DROWNという具体例を出してくれた人に感謝こそすれ、
確かに、その観点は必要でしたね。ちょっと態度を改めます。
しかし、であればこそ、その具体例ばかり強調されてしまうと、
逆にDROWNのみに危険性を矮小化して捉える人がでそうで、なんかモヤっとします。
いまさらSSL v2有効なんて (スコア:0)
そんなサーバ無いやろ…(管理してるサーバをチェックしつつ)
Re:いまさらSSL v2有効なんて (スコア:2, 参考になる)
OpenSSLは今回のバージョンアップまでデフォルトでSSLv2が有効だったそうな。「対策」とはSSLv2をデフォルトで無効にすること。
Re:いまさらSSL v2有効なんて (スコア:5, 参考になる)
POODLE [wikipedia.org] 問題でSSLv3にさえも仕様そのものに脆弱性が見つかっているわけですし、RFC 6176 [ietf.org], RFC 7568 [ietf.org]の推奨通りSSLv2/SSLv3は廃止すべきだと思うんですがねぇ・・
Re:いまさらSSL v2有効なんて (スコア:2, 参考になる)
LibreSSLやBoringSSLはとっくに廃止してるね。NSSも現在削除パッチを絶賛レビュー中。
Re:いまさらSSL v2有効なんて (スコア:2, 参考になる)
自分が管理している機械で外に向けてTLSを喋るデーモンがリンクするライブラリは
OpenSSLからLibreSSLにほぼ差し替え終わった。(まだ僅かに残っているが)
もはやOpenSSLを使ってること自体が結構なリスクだと思う。
今回の件はOpenBSDチームがOpenSSLの体制や現状にぶち切れた理由そのままで草も生えんわ
Re:いまさらSSL v2有効なんて (スコア:2, 参考になる)
古い特殊な端末は、SSL v2のみサポートってあるんですよ。それに接続されるサーバは当然ながらSSL v2をサポートし続けなくてはなりません。
泣きたい
Re:いまさらSSL v2有効なんて (スコア:1)
スマホでなく最新のガラケー()使っている層もいますので
ガラケー対応を切れないサイトはあるんじゃないかね
# キャリアやメーカーに見捨てられるのはAndroidだけではない
Re: (スコア:0)
最新のガラケー事情を知らないので聞きたいのだけど、直近5年以内でSSLv2でないとダメな端末ってどれくらいあるの？
Re: (スコア:0)
なぜ5年？
Re: (スコア:0)
特に根拠はないが、そんだけの期間のSSLv2必須端末の数がわかれば、
対応を切る、切らないの判断がざっくりできるのでは？ってこと。
一台でもあったらサポートを切らないという判断もあると思うけど、一般にそれは過剰品質だよね。