自堕落な技術者の日記

OWASP Night 8thに行ってきて、iOSやAndroidのいろんなアプリのHTTPS接続の検証がいい加減という話を聞いてきたんですが、それよりもAndroidのデフォルトブラウザChromeが失効検証をしない(=証明書の取り消し確認をしない)という事だって十分問題なんじゃないかなぁとか思ったりしてました。

そういえば以前、秋山さんにAndroidだとHTTPS通信がRC4-MD5になっちゃうという話を聞いて、実際にAndroid上のChromeやOperaやFireFoxを見て全く問題ないことを確認し「よしよし安心だ」などと思っていました。

あれれ?待てよ、秋山さんが言っていたのはブラウザではなく、APIで呼び出したときのCipherSuiteの順序関係の可能性もあるなと思ってグーグル先生に聞いて調べてみました。

(文献1)Why Android SSL was downgraded from AES256-SHA to RC4-MD5 in late 2010 (2013.10.13)
http://op-co.de/blog/posts/android_ssl_downgrade/
(文献2)The Register: Android security relies on ZOMBIE CRYPTO, argues infosec pundit (2013.10.16) http://www.theregister.co.uk/2013/10/16/zombie_cipher_list_gives_android_weak_encryption/

あらら、こりゃやべーよ。なんか検索してみても日本では誰も騒いでないみたいだよ。一ヶ月も放っぽりぱなしだったんだなぁ。自分が第一発見者なら公開せずJPCERTとかに報告するんだけどグローバルには公表から1ヶ月も経っているので、国内で騒がれてないようだから書いとくかなと。

結論から言うと、Java 1.4から1.6ぐらい、Android 2.3以降の全てのバージョンで、ウェブブラウザではなくHttpURLConnectionやApacheのHttpClientなどのクラスのAPIを使ったクライアント実装でHTTPS接続する場合には、デフォルトではRC4-MD5といったとても弱い暗号が最優先で使われるために、「必ず」明示的に暗号設定を指定する必要がある。

という事です。JavaやAndroidのHTTPSクライアントを使用する開発者の方は是非対応をお願いしたいです。

AndrodのHttpURLConnectionクラスの利用

早速、簡単なAndroidのHTTPSクライアントをHttpURLConnectionクラスを使って書いて接続し、CipherSuitesを確認してみました。Android 4.0.3で確認しましたが、やはりRC4-MD5が優先になっていました。文献1によればAndroid 2.3.4以降、Android 4.3までダメなようです。

Client Hello Version: TLS 1.0
TLS Version: TLS 1.0
Num Cipher Suites: 35
Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Cipher Suite: TLS_ECDH_ECDSA_WITH_RC4_128_SHA (0xc002)
Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA (0xc004)
Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA (0xc005)
Cipher Suite: TLS_ECDH_RSA_WITH_RC4_128_SHA (0xc00c)
Cipher Suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA (0xc00e)
Cipher Suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA (0xc00f)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_RC4_128_SHA (0xc007)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
Cipher Suite: TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
Cipher Suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc003)
Cipher Suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA (0xc00d)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc008)
Cipher Suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012)
Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016)
Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)
Cipher Suite: TLS_RSA_WITH_DES_CBC_SHA (0x0009)
Cipher Suite: TLS_DHE_RSA_WITH_DES_CBC_SHA (0x0015)
Cipher Suite: TLS_DHE_DSS_WITH_DES_CBC_SHA (0x0012)
Cipher Suite: TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x0003)
Cipher Suite: TLS_RSA_EXPORT_WITH_DES40_CBC_SHA (0x0008)
Cipher Suite: TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA (0x0014)
Cipher Suite: TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA (0x0011)
Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)

例えばAndroid 4.1のNativeCrypto.javaのソースコードを見ると確かにRC4-MD5が優先になっているように見えます。

Oracle JavaのHttpURLConnectionクラスの利用

文献1によれば、そのようなCipherSuiteのデフォルト設定はOracle(Sun) Java JRE/JDKの 設定から来ているもので、Java 1.4.2_19, 1.5.0 (2004)から Java 1.6 (2006)まで 弱いRC4-MD5が優先されていると書いています。

Windows版Sun JDK 1.6.0_21 b07では以下のようになっていました。確かにRC4-MD5優先です。

Client Hello Version: SSL 2.0
Client Hello Version: TLS 1.0
Num Cipher Suites: 19
Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x000004)
Cipher Suite: SSL2_RC4_128_WITH_MD5 (0x010080)
Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x000005)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x00002f)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x000033)
Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x000032)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x00000a)
Cipher Suite: SSL2_DES_192_EDE3_CBC_WITH_MD5 (0x0700c0)
Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x000016)
Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x000013)
Cipher Suite: TLS_RSA_WITH_DES_CBC_SHA (0x000009)
Cipher Suite: SSL2_DES_64_CBC_WITH_MD5 (0x060040)
Cipher Suite: TLS_DHE_RSA_WITH_DES_CBC_SHA (0x000015)
Cipher Suite: TLS_DHE_DSS_WITH_DES_CBC_SHA (0x000012)
Cipher Suite: TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x000003)
Cipher Suite: SSL2_RC4_128_EXPORT40_WITH_MD5 (0x020080)
Cipher Suite: TLS_RSA_EXPORT_WITH_DES40_CBC_SHA (0x000008)
Cipher Suite: TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA (0x000014)
Cipher Suite: TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA (0x000011)

これが、Oracle(Sun) Java JRE/JDK 1.7.0 b147だと以下のようになり、 DHE-RSA-AES128-SHAが優先されており、1.7のとあるバージョンからは問題が直っているのだと思います。

Client Hello Version: TLS 1.0
TLS Version: TLS 1.0
Num Cipher Suites: 21
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA (0xc004)
Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016)
Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
Cipher Suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc003)
Cipher Suite: TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011)
Cipher Suite: TLS_ECDH_ECDSA_WITH_RC4_128_SHA (0xc002)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_RC4_128_SHA (0xc007)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc008)
Cipher Suite: TLS_ECDH_RSA_WITH_RC4_128_SHA (0xc00c)
Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)
Cipher Suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA (0xc00d)
Cipher Suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA (0xc00e)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012)
Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)

この問題を解決するには開発側でなんとかするしかない

この問題を解決するにはHttpURLConnectionで明示的にCipherSuiteやSSL/TLSのバージョンを 指定してやる必要があります。SSLSocketクラスでsetEnablesCipherSuites()メソッドを使う プリミティブな方法もありますが、プロパティで設定する方が簡単かもしれません。

System.setProperty("https.cipherSuites", 
                   "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA," +
                   "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA");
System.setProperty("https.protocols", "TLSv1.2,TLSv1.1");
URL url = new URL("https://www.verisign.com/");
BufferedReader in = 
  new BufferedReader(new InputStreamReader(url.openStream()));
String inputLine;
while ((inputLine = in.readLine()) != null)
  System.out.println(inputLine);
in.close();

国内でもこの問題が広く認知され、対応されるといいですね。

今日はこの辺で

このブログのコメント欄でなひ様に教えてもらった

CodeFromThe70s.org
SSL BLACKLIST 4.0 Firefoxアドオン
SSL BLACKLIST Local Databse Firefoxアドオン
http://codefromthe70s.org/sslblacklist.aspx

を早速インストールしてみました。

これは、以前ブログでも何回か書いたDebianが生成したOpenSSH,OpenSSL鍵の危殆化問題に対応して、やばい鍵に警告ダイアログを出してくれることを主目的としたプラグインなようですが、MD5withほにゃららの証明書をHTTPSで使おうとした場合にも対応しているようです。

とりあえずの自衛策としてはいいんじゃないでしょうか。






＃なんか、間違い探しみたいですか？！（＾＾；（謎）

警告ダイアログっぽくないですね、、、赤・黄色・黒なんか使ってババ〜〜ンとやってほしかったです。

ちなみに、ステータスバーは問題無い証明書だとこんな感じ、、、、




MD5証明書だとこんな感じの警告が出ます。

カンファレンスでMD5ハッシュ衝突を用いたサブCAの偽造が発表されて、わずか数時間でRapidSSLサービスを提供している米VeriSign社はすぐにMD5withRSAのSSLサーバー証明書を発行することを止やめる対応をとりました。この米VeriSignの迅速な対応は私もすばらしいと思います。

日本ベリサインやグローバルサインでもMD5問題の報告をしています。

• 日本ベリサインのグローバル・サーバーIDでは現在、証明書発行を停止しており1月15日よりSHA1withRSAに切り替えて再開する。


• 既存のMD5withRSAのSSLサーバー証明書のオーナーには影響が無い。

と書いてあります、

米VeriSignのTom氏のブログは1月2日に読んだんですが、

米VeriSign Tim Callan氏のブログ(2008.12.30)より
Q: How many certificates are affected?
A: Zero. No end entity certificates are affected by this attack. The attack, when it worked, was a potential method for a criminal to create a new, false certificate from scratch. Existing certificates are not targets for this attack.

日本ベリサインの重要お知らせ(2009年1月6日)より
※尚、この攻撃は、既に発行されたサーバIDを利用した通信の「改ざん」「盗聴」などを可能にするものではありません。お客様のWebサイトにて現在ご利用いただいているグローバル・サーバIDおよびその他全てのサーバIDについて新たなリスクを生じさせるものではございません。

この「既存のMD5withRSAのSSLサーバー証明書のオーナーには影響が無い」ということですが、個人的には果たして本当にそうなのかと考えています。

新規に発行されるSSLサーバー証明書(の署名)はSHA1withRSAになったため偽サブCAは作れなくなりましたが、既存のRapidSSLなどMD5withRSAのSSLサーバー証明書(と私有鍵)のオーナーは、Sotirov氏らの研究成果があればいつでも、現時点で有効な偽サブCAを作れると思います。

研究では新規SSL証明書から偽サブCAを作ろうとしたために、シリアル番号の予見とか衝突計算時間が1日ぐらいといった制約があったわけですが、既存のMD5withRSA証明書と秘密鍵さえあれば多少ゆっくり数ヶ月とか時間がかかったとしても信頼されてしまう偽サブCA証明書は作れるのではと思います。この際、RapidSSLのSSLサーバー証明書の私有鍵がRSA 2048ビット以上であることが必要になると思うんですが(後日解説)そんなRapidSSLのMD5withRSA SSLサーバー証明書と鍵を持ち、研究成果さえ適用できれば可能なのかなと思います。失効していようが、期限切れだろうがかまわないわけです。期限切れになったSSLサーバー証明書と秘密鍵の組が不正利用のための価値を持つデータということになります。

すると、まさかSotirov氏らの研究グループはしないでしょうけど、彼らが安全だと判断して方法を公開してしまった後、公表された手法を用いて数ヶ月後からでもゆっくりと偽サブCAをつくりはじめればよいいことになります。

シリアル番号も、発行されたSSL証明書と、それから作った偽サブCA証明書では、あまり関係が無いように作れるようなので、今後出てくるかもしれない今後何年とかルートが有効である間は有効なこの偽サブCAは失効させることはできません。(いたちごっこです)。ちなみに Equifax Secure Global eBusiness CA-1 のCRLには今回のデモで作った偽サブCAのシリアル番号(0x41)は(まぁ期限切れなのですが)CRLに入っていません。(2009.01.07時点)

既に発行してしまったMD5withRSAのSSLサーバー証明書にも、今後のSHA1withRSAの証明書にも影響無いとしていますが、そうではありません。RapidSSLのサービスを利用しているかどうかに関わらず、どこのSSLサーバー証明書を使っていたとしても等しくSSL中間者攻撃の被害の可能性があるということです。

私はこの問題を解決するには、やはり、

・Windows UpdateやFireFox Updateなどで、信頼するルート証明書ストアからMD5withRSAのルートCA、少なくともEquifaxのルートは削除する)
・ルートCA・サブCAとウェブブラウザが基本拡張(BasicConstraints)のpathLen制約をサポートする
・ブラウザの設定でMD5withRSA証明書をはじくようにする(FireFoxプラグインができないでしょうか？)

しか無いのかな、、、と考えています。

勉強不足で思い違いをしているようでしたら、ご指摘いただけると有り難いです。

参考リンク：

・米VeriSign Tim Callan氏のブログ：This morning's MD5 attack - resolved (2008.12.30)
・Alexander Sotirov氏のブログ：Verisign and responsible disclosure (2009.01.06)
・セキュリティmemo：追記 MD5 considered harmful today: Creating a rogue CA certificate (2009.01.07)
・日本ベリサイン：MD5アルゴリズムへの衝突攻撃によるSSLサーバ証明書の偽造に関する報道について(2009.01.06)
・GMOグローバルサイン：MD5アルゴリズムへの衝突攻撃によるSSLサーバ証明書の偽造に関する報道について(2009.01.06)

自堕落な技術者の日記 : 続：MD5の商用ルートCAの終焉 - livedoor Blog（ブログ）

う〜〜む、続々荒野の七人みたいなタイトルになってきましたね、、、（　´∀｀）

今回のMD5ニセサブCA問題について幾つか補足しておきます。

EV SSL証明書とMD5ニセサブCA問題

今回の問題のEV SSLサーバー証明書への影響についてCA Browser Forum議長
EntrustのTim MosesはIETFの関連MLに2009年1月1日以下のようにポストしています。

・EV SSLサーバー証明書を発行するCAでMD5を使って証明書に署名するCAは無い
・EV証明書は自動的な手続きにより発行されることは無い

EVのガイドラインではMD5は使えないようになっているので、これは皆さん遵守しているということでよかったです。また、今回のMD5ニセサブCA問題は、自動化された発行プロセスにより1日後のシリアル番号が予見できることに依存しているので、自動発行でないEVはこの問題の影響を受けにくいということになるかと思います。

今回の問題に関する各社の対応

幾つかの認証サービスのサイトを見ていますが、今回の問題について問題や対応の公表をしているところはまだ無いようです。RapidSSLなんかは早めにアナウンスする責任があると思うんですが、、、、

MD5のルートCAだとダメなのか

今回のニセサブCAは、衝突計算に要する時間(1〜2日)後の証明書シリアル番号が自動化された証明書発行プロセス予見されることが必要となるので、全てのMD5をルートCAに影響あるわけではないようです。

また、CA証明書がMD5withRSAであるかどうかは直接は問題なく、MD5withRSAの証明書を発行しているところが問題となるわけですが、ルートCA自己署名証明書がMD5withRSAなら発行する全ての証明書もまたMD5withRSAである場合が多いので「問題の影響有り」ということになるかと思います。

とりあえず、こんなところで、、、、

自堕落な技術者の日記 : MD5の商用ルートCAの終焉 - livedoor Blog（ブログ）

MD5 considered harmful today

前に書いたブログの続編です、、、、

今回はプレゼン資料やサイトの詳細情報などから、今回の問題を解説してみたいと思います。

2008年12月30日にドイツのベルリンで開催された25th Chaos Communication Congress(25C3)というカンファレンスでAlexander Sotirovらの研究グループが2007年に公表されたハッシュアルゴリズムMD5の脆弱性の攻撃方法を利用して商用のMD5withRSAのSSLサーバー証明書を発行しているサービス(RapidSSL、RSA Data Security、VeriSignなど)を利用して任意のHTTPSのサイトを中間者攻撃できることを実証したようです。

問題の詳細は以下のサイトで説明されています。
MD5 considered harmful today
http://www.win.tue.nl/hashclash/rogue-ca/

ニセサブCA作成手順

実証例として紹介されているのはRapidSSLから発行されたSSLサーバ証明書をから信頼されるニセサブCAを作ってしまいほぼ全てのブラウザではデフォルトで信頼されてしまうニセのSSLサーバー証明書をいくらでも発行できるサブCAを作ってしまっています
。

EquifaxルートCAは、現在GlobalSignなどにも一部移管されているようですが、デモで用いたのはRapidSSLのEquifax Secure eBusiness CA-1というルートCAを利用しています。RapidSSLのサービスは2005年3月まではFreeSSLというサービス名でした。(参考)。RapidSSLはGeoTrust Inc.の低価格ブランドのSSL証明書サービスでしたが、2006年5月にGeoTrust Inc.がVeriSign Inc.に買収されています。

さて、手順はこんな感じ、、、、

(1) RapidSSLのサービスは
　　Equifax Secure eBusiness CA-1 (RootCA) → 利用者SSLサーバー証明書
　　の直接信頼モデルになっています。
　　発行するSSL証明書はMD5withRSAで署名されており、
　　シリアル番号は連続番号になっており予測可能です。
(2) まず、SSLサーバー証明書をフツーに発行してもらい現状のシリアル番号を確認します。
(3) MD5ハッシュ衝突の脆弱性を突いて必要なSSLサーバー証明書(=ニセサブCA)の
　　tbsCertificateの部分(証明書の署名アルゴリズムと署名値を除く
　　部分)と実際に送信する証明書発行要求を計算します。要件は以下の通り。
　　【ニセサブCA側】
　　・シリアル番号は予想値を使う(計算に1日かかるならシリアルは何番？)
　　　計算に要する時間(1〜2日)との兼ね合いになる。
　　・識別名は本物のサブCAっぽいと良い
　　・元はSSLサーバー証明書(エンドエンティティ証明書)だが
　　　ニセサブCAが欲しいのでbasicConstraint拡張はcA=TRUE
　　・CRLDP、AIAなど失効情報を提供する拡張はあえて入れない
　　　ことで、多くのブラウザは失効検証しないので
　　　ニセサブCAは失効をチェックされることは無くなり長く使える。
　　・ハッシュ値の調整(衝突ビット)にはNetscapeComment拡張など検証処理には
　　　使われないものを使う。2007年に公表されたMD5のchosen-prefix collision
　　　(指定された先頭値による衝突)攻撃を使いハッシュ値が一致するように
　　　計算する。
(4) 生成したtbsCertificateと対になる実際に送る用の証明書発行要求(CSR)を
　　約1日後そのシリアル番号のものが出そうな時刻に連続して、
　　目的のシリアル番号の証明書が発行されるまで発行要求を続ける。
(5) 発行された目的のシリアル番号のエンドエンティティ用の
　　フツーのSSLサーバー証明書から証明書から署名値部分を切り出して
　　(3)で作っておいたニセサブCA用のtbsCertificate部分と組み合わせて
　　ニセサブCA証明書を作る。(4)の時に生成された対応する秘密鍵と
　　組み合わせてニセサブCA作成は完了。これで何枚でも既存のどんな
　　ホストであろうが信頼されてしまうニセサーバー証明書は発行できる。

この(3)の別原像を探す計算に要する時間は、以下の環境でおよそ1〜2日だそうです。
(a) プレステ3が200台構成のクラスタ
(b) デスクトップPCが8000 CPUコアのクラスタ
(c) Amazon Elastic Compute Cloud (EC2) 20,000米ドル分

デスクトップよりもプレステ3がこんなにもスゴイって事にびっくりしました。デュアルコアのデスクトップ4000台を個人で準備するのは無理ですが、プレステ3なら知り合いをかき集めれば200台集められるなんて人もいるんじゃないでしょうか。

EC2の環境は最初の準備が大変だそうですが、実機で数百〜数千台準備するよりもお手軽ですし値段も大したこと無いですよね。ニセサブCAさえ作れれば何枚でもSSLサーバー証明書を出せるのでたった200万円は安いかも。別の最適化を使えば20万円でもいけそうだということです。RapidSSLには無償再発行の分もあったりするので、目的のニセサブCAを得るためにRapidSSLに払ったのは7万円弱なんだそうです。

デモサイト

カンファレンスではデモ用無線LAN環境を提供して、そこから全てのHTTPSサイトに接続してもすべて中間者攻撃され通信は盗聴されているというデモを行った模様です。

Alexander Sotirovのサイト(http://www.phreedom.org/research/rogue-ca/)では、Rapid SSLから発行されるはずのSSLサーバー証明書を全てのブラウザが信頼してしまうニセサブ証明書にしてしまい、そこからニセのSSLサーバー証明書を発行しています。

デモサイトのURLはこれです。
https://i.broke.the.internet.and.all.i.got.was.this.t-shirt.phreedom.org/
この鍵が本当の不正に使えないようにあえてニセサブCA証明書やニセSSLサーバー証明書を2004年7月31日〜9月1日の有効期限に設定しているそうです。例えばPCの時計を2004年8月15日に設定して接続してみますと





のようにブラウザは信頼してしまう正しい証明書をニセのサブCA(MD5 Collisions Inc.)が発行しています。





現在時刻でやったら期限切れですと出ます。

IEやFirefox、ケータイなどほとんど全てのブラウザで信頼されてしまうニセのサブCAが作れてしまったので、信頼される不正なSSLサーバー証明書をどんなホスト名に対しても発行できてしまいます。

攻撃方法の詳細の公開について

この問題の対象となっている認証サービス（やブラウザ？）が対策を講じるまでは、この攻撃方法の詳細は論文公表しないそうで、数ヶ月の猶予はあると述べています。既に認証サービスと研究グループは調整を行っているそうです。

実際の盗聴などの中間者攻撃のために

以上の方法で信頼されてしまう不正なサブCAとSSLサーバー証明書を入手できますが、これを盗聴などの中間者攻撃に用いるには、DNSスプーフィングなどホスト名とIPを騙す必要があります。安全でない無線LANアクセスポイントやルーターなどもリスクとなります。

紹介された対応策について

カンファレンスのスライドでは主要な対応策として
・シリアル番号を乱数にし予測不能にする
・証明書発行要求の処理時間をランダムな長さとする
・ローカルOCSPをたて、不正サブCAのブラックリストを見るようにする
などが紹介されいていました。

せきゅめもさんとこでは「MD5」を使ったら弾くようなことを書いてありましたが、これは私も賛成です。ブラウザの設定でTLVv1、SSLv3など選択できるようなものがありますが、同様にMD5を使わない、将来的にはSHA1を使わない、警告を出すなどの設定があると良いかなと思います。

あと、今回の不正サブCAを作る方法では証明書チェーンの段数が一段増えることになるので、ルートCAのpathLenConstraintにより最大の段数の制限することとし、ブラウザの検証もこれをチェックするようになると良いかなと思います。

う〜〜ん、眠い、、、、今日はこの辺で、、、、、、

参考：
セキュリティホールmemo: MD5 considered harmful today: Creating a rogue CA certificate(win.tue.nl, 2008.12.30)
TechCrunch:MD5コリジョンでインチキ認証局は作れる（ネットにとっては悪い報せ)

MD5 considered harmful today

昨日、2008年12月30日、MD5の脆弱性をついてMD5ベースの商用ルートCAを使って信頼されてしまうニセCAを作れちゃったというものらしいです。NIST SHA3コンペのMLやIETFのS/MIME、PKIXのMLに以下のメールが流されました。

Russ Housleyのメール
From: Russ Housley
Subject:Further MD5 breaks: Creating a rogue CA certificate
Date: 2008.12.31 01:05

http://www.win.tue.nl/hashclash/rogue-ca/

MD5 considered harmful today
Creating a rogue CA certificate

December 30, 2008

Alexander Sotirov, Marc Stevens,
Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, Benne de Weger

We have identified a vulnerability in the Internet Public Key
Infrastructure (PKI) used to issue digital certificates for secure
websites. As a proof of concept we executed a practical attack
scenario and successfully created a rogue Certification Authority
(CA) certificate trusted by all common web browsers. This certificate
allows us to impersonate any website on the Internet, including
banking and e-commerce sites secured using the HTTPS protocol.

Our attack takes advantage of a weakness in the MD5 cryptographic
hash function that allows the construction of different messages with
the same MD5 hash. This is known as an MD5 "collision". Previous work
on MD5 collisions between 2004 and 2007 showed that the use of this
hash function in digital signatures can lead to theoretical attack
scenarios. Our current work proves that at least one attack scenario
can be exploited in practice, thus exposing the security
infrastructure of the web to realistic threats.

年末にちょっとビックニュースですね。とうとう、こんな時が来ましたか、、、
これから、サイトや論文読んでみます。

以下の商用CAがMD5のルート証明書を出しているようです。

- RapidSSL
- FreeSSL
- RSA Data Security
- Thawte
- VeriSign

＜追記＞
よく読んでみるとルートがMD5であることでなく、MD5(withRSA)で署名された証明書を発行しているCAが問題なんですね。まとめは、別途書きます。