自堕落な技術者の日記

2015年5月7日に「RFC 7525 TLSとDTLSの安全な利用に関する推奨事項(Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS))」が公開されました。

昨年あたり、SSL/TLSで使われる暗号アルゴリズム、プロトコルや実装にいろいろな問題が見つかり、製品をそのままデフォルトで使っているとロクなことが無いわけですが、どんなことに注意しながら実装や設定をしなければならないかをベストカレントプラクティス(現時点での最良の慣行)としてまとめたRFCだそうです。

最近、SSL/TLSの設定ネタでお話しする機会を頂いたりしておりますが [1] [2] 、RFC 7525をざっと見たところ、概ね違ったことは言ってないようにおもいます。今日は、RFC 7525について、ちょっと見てみたところを書いていきたいと思います。

RFC 7525の目的

RFC 7525の目的は、仕様から以下の2つなのかなと思います。

• 最低限満たすべき推奨事項を示す。
• TLS 1.3が普及するまでのつなぎで対応しておくべき事を示す。

RFC 7525のポイント

各節から拾ってきたRFC 7525のポイントをまとめると以下のようになります。

• 3.1.1節 TLSプロトコル
  • POODLE等の対策として、SSLv2、SSLv3の利用禁止(MUST NOT)
  • CBCモード対策としてTLS 1.0の利用抑制(SHOULD NOT)
  • TLS 1.2の実装必須(MUST)
  • TLS 1.2、TLS 1.1、TLS 1.0の順で優先(MUST)
• 3.1.2節 DTLSプロトコル
  • DTLS 1.0の利用抑制(SHOULD NOT)
  • DTLS 1.2の実装必須(MUST)
  • DTLS 1.2、DTLS 1.0の順で優先(MUST)
• プロトコルその他
  • 3.1.3節 TLS 1.x からSSLv2、SSLv3のフォールバック禁止(MUST NOT)
  • 3.2節 HSTS(HTTP Strict Transport Security)ヘッダのサポート必須(MUST)
  • 3.3節 CRIME攻撃等の回避のためTLS圧縮を利用抑止(SHOULD)
  • 3.4節 セッション再開でセッションチケットの通信における認証と暗号化は必須(MUST)
  • 3.5節 TLS再ネゴシエーションが必要な場合、renegotiation_info拡張のサポート必須(MUST)
  • 3.6節 Server Name Indication(SNI)のサポート必須(MUST)
  • 4.5節 Truncated HMAC TLS拡張の利用禁止(MUST NOT)
  • 6.5節 証明書失効検証では、OCSP、status_request・status_request_v2 TLS拡張、OCSP stapling拡張を利用すべき(SHOULD)
• 4節 暗号スイートの推奨
  • NULL暗号スイートでの接続禁止(MUST NOT)
  • RC4暗号スイートでの接続禁止(MUST NOT)
  • EXPORT等、112ビット未満の暗号スイートでの接続禁止(MUST NOT)
  • 128ビット未満の暗号スイートでの接続抑止(SHOULD NOT)
  • TLS_RSA_WITH_*の接続抑制(SHOULD NOT)
  • DHE、ECDHEなどPFSをサポートする暗号スイートの優先接続のサポート(MUST)
  • TLS_{DHE,ECDHE}_RSA_WITH_AES_{128,256}_GCM_SHA{256,384}を推奨(RECOMMENDED)
• 4.3節 公開鍵長
  • DHE鍵交換の場合、DH鍵長は2048bit以上を推奨(RECOMMENDED)
  • ECDH鍵の場合、192bit未満の曲線は利用抑止(SHOULD NOT)
• 4.3節 証明書
  • RSA場合、鍵長2048bit以上の証明書を推奨(RECOMMENDED)
  • 証明書の署名はSHA-256の利用を推奨(RECOMMENDED)

RFC 7525を見て気になった点

気になった点や感想的なものをまとめてみます。

• 最小限の推奨事項といいながら、MUST、SHOULDに従ったとするとかなり厳格な要件で、これに対応できるのは最新のウェブブラウザ、ウェブサーバーのみであり、ちょっと前の組み込み機器、SSLアクセラレーターなどは、これらの要件を満たすことは不可能かなと思います。
• やはり、最新のソフトウェアのみで対応すればよい環境と、後方互換性を必要とする環境とで区別して推奨事項を述べるのがよいのではと思います。
• RSA鍵交換を抑制(SHOULD)する一方で、SEED、IDEA、Camelliaなど言及されないアルゴリズムも多く、これらの扱う際に混乱します。
• PFSやRC4を強調しすぎで、CBCモードは軽視されている。
• 鍵長の話はもう少しシンプルに纏められたのではと思う。文章が整理されておらずわかりにい。
• アプリケーションプロトコル(HTTP, SMTP, IMAP, IRC, XMPP等)の言及はあまり役立たない。
• 証明書要件はRECOMMENDEDと、かなり緩め。

RFC 7525の良かった点

一方、このRFC 7525の良かった点はこんなとこかなと、、、

• 何を根拠(Rationale)としてそのような設定を要求するのかが明らかになっており良い。
• 実装(implementation)と展開(deployment)を分けて書いてあるのはよい。
• Opportunistic Securityについて、単なるフォールバックよりも危険が懸念されることを明確にし、RFC 7525の対象外としたのは良い。
• 証明書失効の課題が整理されたのは良い。
• 特に、プロプライエタリな失効検証がスケールしない点を指摘したのは良い。

おわりに

RFC 7525はベストカレントプラクティスと言いながら、少しトガった要求事項になっていて、最新の環境だけでしか動かない感じです。InternetWeekでお話をした時から、状況もいろいろ変わっていて、現時点での暗号スイート設定のおすすめは、近々書きたいと思っています。あと、メジャーなサーバーでの設定ファイルを作るウェブツールなども作ってしまいたいと思ってるんですが、なかなか先に進まない。

来週の情報セキュリティExpoでは、IPAさんのブースで私も委員として作成に携わらせて頂いた「SSL/TLS暗号設定ガイドライン」の説明もあったりするそうです。このガイドは主にサーバー管理者向けに幾つかのケースに分けてセキュリティ要件を定めて設定例を示したもので、RFC 7525 よりは、より具体的にどうすればよいかがわかるようになっています。最後の委員会が終わったあとも、リクエストがあったので追加原稿はいろいろ出させて頂いたんですが、どうも最終的に、特に暗号スイートの設定について、思った通りのものにはならなかったですね。いろんな意味で後悔しています。

今日はこの辺で

SSL/TLS CipherSuiteウォッチャーの@kjurです。

TechCrunch JPに昨日こんな記事が掲載されました。

Twitterが将来の暗号解読を防ぐため全サイトにわたってPerfect Forward Secrecyを採用 (2013年11月23日)
http://jp.techcrunch.com/2013/11/23/20131122twitter-enables-perfect-forward-secrecy-across-sites-to-protect-user-data-against-future-decryption/

最近、SSL/TLS のCipherSuiteについて、いろいろ趣味で調べているんですが、 そんなに大騒ぎするような事なんかなと思ったので ブログに書こうかと思います。

PFSとは

記事にある通り「Perfect Forward Secrecy(PFS)」は確かに決まった訳語が無いようで 単に「PFS」という略語で呼ばれたりしています。 私は「将来に向けた機密保護機能」と訳すのが良いかと思っています。

IPsecVPNでは既にいろんな製品で組み込まれていて、オプションでこれを 有効にすることができ、SSL/TLSの場合には、鍵交換に「ECDHE」か「DHE」を 使った場合に「PFS」を有効にしたと言う事ができます。

鍵交換にECDHE、DHE、ECDH、DHを使わずに認証の公開鍵暗号と 同じ物(RSA、ECDSA、DSS(DSA))を使った使った場合 (例えばTLS_RSA_WITH_AES_128_CBC_SHAなど)、 あるときSSL/TLS通信の全てを記録しておいて、 後で認証に使った秘密鍵が漏洩した場合、 通信の全てを復号することができます。

この問題が最近フォーカスされるようになったのは、エドワード・スノーデン氏の NSA情報漏洩事件に端を発しており、NSAが巨大なデータセンターで市民の全ての 通信内容を「将来になって解析できるようにSSL/TLS暗号通信のまま」保管している という噂があるようですが、通信内容を暗号化したまま全て記録されていたとして、 「将来になって」公開鍵暗号の秘密鍵が漏洩したり解読されたりしても 通信内容が漏洩する事は無いという機能が「Perfect Forward Secrecy」です。

鍵交換にECDHやDHを使った場合、認証に使う鍵と鍵交換の鍵は 別になるので、通信の漏洩の可能性はすくなくなります。 これを「(Perfectでない)Forward Secrecy」を持つというようです。

鍵交換にECDHEやDHEを使った場合、ECDHやDHと使った場合に 比べて一定時間の後に定期的に異なる鍵で鍵交換を行い 「将来に向けて機密保護されている(Perfect Forward Secrecy)」ことに なります。 "E"はephemeral(一時的)の"E"です。

DH、DHEは鍵長1024bitで80bit相当の暗号強度があると言われていますが、 RSA 1024bitと同程度の暗号強度で昨今では十分な暗号強度でないとされています。 ECDH、ECDHEでは256bitの曲線が使われRSA暗号で言えば3072bitのRSA鍵に相当する 128bit暗号強度があるのでDH、DHEよりはECDH、ECDHEを使うべきだと言われています。

鍵交換にRSAを使うよりもECDHEやDHEを使った方が余分に計算コストがかかりそうなことは 想像できると思います。今回のECDHEやPerfect Forward Secrecyの問題について 詳しく技術的に解説しているリンクとして1年前に公開された以下のページがあります。

SSL/TLS & Perfect Forward Secrecy
Vincent Bernat
http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html

この中で、鍵交換にRSAそのものを使った場合に比べて、サーバーにおいて DHE_RSAの場合3倍、ECDHE_RSAだと1.27倍の計算コストがかかるそうです。 DHEだとかなりの負荷になりますが、ECDHEならそれほどの負担には ならなそうだという事になります。

最後に、証明書を発行するサービスの人でも平気で 「ECDHEを使うにはECDSAの楕円暗号の証明書が必要だ」と 誤解している人がいますが、 鍵交換と認証に使う証明書の暗号は全く独立です。 鍵交換が楕円(ECDHE)でもサーバー証明書はRSAが使えます。

で、TwitterのPFSつまりECDHE対応は?

というわけで、ECDHE対応になったらしいという

• https://twitter.com
• https://api.twitter.com
• https://dev.twitter.com

を見てみました。結果からいうとPFSに対応したのは twitter.comとapi.twitter.comだけであって、dev.twitter.comは PFS対応ではないことがわかりました。 従って「全サイトにわたってPerfect Forward Secrecyを採用」というのは 間違っていることになりますよね。

twitter.comとapi.twitter.comのSSL/TLS CipherSuiteやプロトコルのサポート状況の特徴を まとめてみました。

• SSLv3.0、TLSv1.0、TLSv1.1、TLSv1.2をサポート
• PFS対応としてECDHEをサポートするがECDH、DHE、DHはサポートしない
• AES_GCM、SHA2をサポート
• 3DES_EDE、RC4-SHA、RC4-MD5など弱い暗号もサポート

特にRC4-MD5をサポートしている事は以前のブログで 紹介したようにJava、AndroidなどのAPIから利用した場合にRC4-MD5といった 弱いCipherSuiteが優先的に選択されてしまう可能性があるので 注意してください。 (参考: JRE 1.4-1.6やAndroidのAPIを使ったHTTPS接続のCipherSuitesがRC4-MD5を優先しているかなりヤバい話(2013.11.17))

dev.twitter.comについては全く上とは独立でなかなか面白いです。

• SSLv3.0、TLSv1.0のみサポート
• ECDHE、DHE、ECDH、DHをサポートしない
• 3DES_EDE、RC4-SHA、RC4-MD5など弱い暗号もサポート
• CAMELLIA、SEEDもサポート

各ブラウザで繋いでみると

各ブラウザで繋ぐとどうなるのかツイッターのサイトをウェブブラウザで開いて 通信のプロパティをそれぞれ見て見ましょう。最初はChromeです。

ちゃんとChromeはECDHEになっています。AES GCMを使っているのでさらに良いですね。

FirefoxもちゃんとECDHEになっていますね。ただ、RC4なんでちょっと残念。

IE8 on Win7ではECDH_P256と表示されます。NIST P-256曲線の楕円暗号で鍵交換している のがわかるのは良いですが。ECDHと表示されちゃいますね。 ただ、パケットキャプチャしてみるとわかるんですが、ちゃんとECDHEで鍵交換しています。 IE8はECDHやDHなどephemeralではない鍵交換はサポートしていないので。

おわりに

以上、TwitterがPFSに対応したというので、 ちょっと調べてブログ書いてみました。 ECDHEをサポートするサイトなんてちっとも珍しくもないので 「PFSに対応した」と大声でいうのも恥ずかしい話だと思うのですが、 PFSに端を発して問題が理解されECDHEなどのCipherSuiteが 注目されるのは良い事だなと思いました。

残念だったのはこうした移行の前にtwitter.comのサポートするCipherSuiteの魚拓を 取っとかなかったことです。自動的に情報収集する仕組みを作るかなぁ・・・

今日はこのへんで

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();

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

今日はこの辺で

SSL/TLS CipherSuiteウォッチャーの@kjurです。

2013年11月13日にマイクロソフトから度肝が抜かれるほどびっくりした Windows 7 SP1以降の「重要」更新プログラムが出てもうアップデートした人も いるんじゃないかと。既にSurface Pro 2などのWindows 8.1にはこの 更新が適用されているというので二度見しちゃいましたよ。

マイクロソフトセキュリティアドバイザリ(2868725) RC4を無効化する更新プログラム
http://support.microsoft.com/kb/2868725/ja
http://technet.microsoft.com/ja-jp/security/advisory/2868725

BEAST対策でRC4マンセーみたいな感じだったのに、RC4使えなくしちゃうんですよ。いきなりですごくないですか? 証明書とかSHA1を止める準備も着々と進んでいてマジでマイクロソフトやるなぁと度肝を抜かれました。

となりの人がこのパッチを適用されたWindows 8.1のSurface Pro 2を持っているのでちょっとマシンをお借りしてCipherSuite比較してみました。(Special Thanks To 隣の平井堅に似た人)

ちなみにこっちはWindows 7 SP1でRC4無効化パッチ(KB2868725)未適用のIE8.0のCiphrSuite。

Client Hello Version: TLS 1.0
TLS Version: TLS 1.0
Num Cipher Suites: 12
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
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_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
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_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)
Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)

そんでこれがWindows 8.1 Pro、IE 11.0.9600.16384のCipherSuite。

Client Hello Version: TLS 1.2
TLS Version: TLS 1.2
Num Cipher Suites: 19
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
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_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)
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_DHE_DSS_WITH_AES_128_CBC_SHA256 (0x0040)
Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 (0x006a)
Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)

特徴的なのはこんなとこ。

• 本当にRC4はなくなってしまった。
• ClientHelloではClientHelloのバージョンもTLSバージョンもTLSv1.2になっており、接続に失敗してもTLSのバージョンをダウングレードしたりはしないんですが、頂いた報告や私も確認してみた所、クライアントがTLSv1.2のみを要求して、サーバーがTLSv1.0と返してきてもハンドシェイクできてしまうみたいです。iOSとか他の実装はClientHelloをダウングレードしてやり直すものが多いですが。本来ならばClientHello TLSv1.0、TLS versionがTLSv1.2とするのが正しいClientHello要求だと思います。
• 対応するCipherSuiteが12から19に増えました。
• SHA2系のCipherSuite、AES GCMのCipherSuiteが追加されました。
• でもRSA GCMは無くてECDSA GCMだけでかなり残念
• CipherSuiteの優先順位が微妙

GCMの対応はAndroid、MacOS X版Chrome、Android版Operaに続いてIE11もとうとう来たかという感じですね。Firefoxの対応が待たれます。過剰なBEAST対策祭りでAES止めちゃってRC4しか残してないとかRC4と3DESしか残してないとかいうサイトはつながらなくなったり、弱い暗号になっちゃったりするかもしれないのでケアしないといけないかもですね。

今日はこの辺で

証明書ハンターであり、CipherSuiteウォッチャーの@kjurです。

ChromeのWindows、Macの新しい安定版版 31 が昨日、11月13日にリリースされたので 早速CipherSuiteを見てみました。

これがアップデート前のChrome 30

Chrome 30.0.1599.101 on Windows 7 SP1
Client Hello Version: TLS 1.0
TLS Version: TLS 1.2
Num Cipher Suites: 20
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x006b)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
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_128_CBC_SHA256 (0xc023)
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_128_CBC_SHA256 (0xc027)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x0067)
Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)

これがアップデート後のChrome 31

Chrome 31.0.1650.48 on Windows 7 SP1
Client Hello Version: TLS 1.0
TLS Version: TLS 1.2
Num Cipher Suites: 18
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e)
Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
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_RSA_WITH_RC4_128_SHA (0xc011)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)

CipherSuiteの数が20から18に減っています。

特徴的なところは

• 30から31になってGCMでないSHA2は全て削除された
• 30までGCMには対応していなかった
31になったAES GCM SHA2が新たに追加された
• ちょっと順序も入れ替わっていてAES GCM SHA2が優先になっている

といったとこでしょうか。

これからOWASP Nightです。今日はこの辺で

新型Nexus 5をゲットしたgregさんが、週末SSLハンドシェイクしたところのパケットキャプチャを送ってくれたのでNexus 5 Android 4.4 KitKat上のChrome 30.0.1599.105のCipherSuiteを見てみました。結果から言うとAndroid 4.3.1 Chrome 30.0.1599.96と、サポートしているCipherSuiteも、優先順位も含めて全く変わりがありませんでした。まぁ、そりゃそうだよね。

CipherSuiteラヴな人にとってはNexus 5は喰いつきポイントは無かったってことで。gregさんいつもありがとう。