Googleはオンラインセキュリティブログでまもなく旧式のSSL 3.0のサポートを廃止すると発表した。SSL 3.0の脆弱性に関する報告が発表され、CVE-2014-3566が提示された(しかし、この記事の執筆時点ではCVEデータは封印されている)。この脆弱性はSSL 3.0のサポートを廃止することで対処できる。より具体的に言えば、SSL 3.0のCBC (Cipher Block Chaining)のサポートをやめればいい。
この問題はTLSとの互換性フォールバックに関わっている。このフォールバックでは通信が成功しなかった場合、より低いレベルでの再ネゴシエーションを許可している。クライアントとサーバの両方がTLSのプロトコルの現在のバージョン(執筆時点では1.2)をサポートしている場合もあるが、通信時のエラーによってブラウザとサーバがより低いレベルでの再ネゴシエーションを実施する場合がある。TLS 1.0はSSLの後継(元は12年前の今週に発表されたNetscape Navigatorで実装された)だ。TLS 1.0の実装はSSL 3.0へフォールバックすることが許されていた。このSSL 3.0に今回、脆弱性が見つかった。TLSの新しいバージョンは特定の暗号を禁止している。例えば、TLS 1.1は8年前にCBCアタックのサポートを廃止している。また、次期バージョンであるTLS 1.3はCBCとRC4のサポートを全面的に廃止している。
攻撃にはふたつの段階がある。ひとつは、パケット注入を通じて、クライアントとサーバのコネクションのセットアップの時にMITMアタックによって、コネクションがリセットされるという段階。その後、クライアントとサーバはより低いレベル(例えば、SSL 3.0)で再ネゴシエーションを強要される。これが実行されると、POODLE(Padding Oracle On Downgraded Legacy Encryption)という、報告された攻撃が実行でき、通信中にキーの一部分が流出する。SSL 3.0はRC4のストリーム暗号(これは、すでに脆弱性があることで知られている)かCBCモードのブロック暗号を使う。今回は後者に脆弱性があると疑われており、SSLはこのふたつのモードしか提供しないため、SSLのサポートを止める必要がある。この攻撃は、サーバへ始めのブロックの最後のバイトだけが違う256のパケットを送信することで、ブロック暗号の最後のバイトを分析して実現する。バイトが正しいリクエスト以外は拒否するが、その結果、情報が1バイト漏洩する。1バイトずつシーケンスをずらすことで、攻撃者はペイロードの任意の数のバイトを推測でき、これによってSSLで保護されていたはずのCookieの値が漏洩する可能性がある。
SSL 3.0のサポートを簡単に廃止できないシステムの場合は、TLSのTLS_FALLBACK_SCSVを使ってダウングレードを無効にできる。これによって、自動的にTLSのハンドシェイクの一部を実施するのではなく、低レベルのコネクションを再実施するかどうかをクライアントが決められる。
この問題は現在開発中のHTTP/2とも関係する。現時点では、HTTP/2はファイナルコールの最中だ。Issue 612は議論を呼んでいるセクション9.2.2の変化について書いている。このセクションはHTTP/2のコネクションで使われる暗号化方式を制限するというものだ。ドラフトの初期のバージョンでは、TLS上での追加のネゴシエーションで暗号化方式が有効無効を判断するようになっていた。現在、このセクションはCBCモードを使ったコネクションをデフォルトで無効にしておくように要求している。他の点ではクライアントとサーバで問題のないバージョンでTLSのコネクションが確立されていた場合でも、無効にしておく必要がある。先週、Googleが公表し、SSL 3.0を無効化することになった、コネクションの最初の256バイトの情報漏洩が起こる可能性があることに関心が集まった。さらに、HTTP/2自体もTLSのライブラリに要件を追加する予定はない。
進捗はしているものの、この問題はワーキンググループに混乱を起こしている。Roy Fielding氏はセキュリティの要件が組み込まれているアプリケーションプロトコルは正気の沙汰ではないと言い、9.2.2をサポートしないと公言している。Jettyの開発者(Greg Wilkins氏)は将来を見据えた実装をすることは不可能だと言い、AppleのMichael Sweet氏も9.2.2を9億の台のiOSとOSXのデバイスに実装するのは不可能かもしれないと言っている。また、Microsoftもこの9.2.2の提案に反対している。
SSL 3.0と脆弱性のある古いCBCモードを排除することで、Googleはクライアント-サーバ間のコネクション(TLS 1.2を使った)を安全にし、コネクションが攻撃されたことで実現可能になる攻撃を緩和することを期待している。これによって、HTTP/2の仕様の障害を排除し、TLS 1.2以上のバージョンに依存するようになるかもしれない。来月示される予定のTLS 1.3(CBCモードをブロックしている)はHTTP/2を前に押し進めるのに十分な仕様な可能性もある。そうでなければ、私たちはこのサマリとともに取り残されるだけだ。
| 私が知る限り、ホワイトリストではなくブラックリストを使って運用されているサーバで | 9.2.2を実装すれば、脆弱ではないと思います。 クライアントがホワイトリストを使って、かつサーバがブラックリストを使って、 かつ、サーバが暗号化方式の選択に影響を持ち、かつ、サーバがあなたの言う3つのパターンにマッチする暗号化方式をすべて禁止し、 かつ、暗号化方式名がそれらのパターンと異なり、かつ追加のパターンが構成されていなければ、脆弱ではないと思います。 つまり、あなたは単に脆弱であることを明らかにしたのです。