自堕落な技術者の日記

2015年5月12日に、IPAのサイトでCRYPTRECのWGで作成した 「SSL/TLS暗号設定ガイドライン」が公開されました。

このSS/TLS設定ガイドラインが作成された背景や概要は菊池先生の CRYPTRECシンポジウム2015での 講演資料にわかりやすく書いてありますので、これをご覧頂くのが 一番よいかと思います。

このガイドラインはサーバー管理者向けに、 なるべく暗号のことは細かく触れずに、 (とはいえ細かい暗号の話も多いですが、、、) 昨年度、特に多かったSSL/TLS関連の様々な脆弱性に対して、 どのように設定すればいいのかを解説しています。 紹介されているコラムなど読み物としてもなかなかおもしろいので、 是非ご覧いただければと思います。

ガイドラインでは、用途に応じて3つのタイプに分けて設定を紹介しています。

• 政府・金融・医療など高いセキュリティが求められる場合の設定→高セキュリティ型
• 一般的な推奨設定→推奨セキュリティ型
• 古いブラウザ、ゲーム機、フィーチャーフォンなどへの対応も必要な場合→セキュリティ例外型

特に暗号スイートやプロトコルの設定を、昨今の脆弱性・暗号危殆化に照らして どのように設定するのかというのが、管理者のみなさん悩ましいところだと思うのですが、 これを巻末のAppendixにて、具体的にどのサーバーではどう設定すればよいのかを 記載しています。

ただ、あれを全部読んで動く設定ファイルを作るのってページ数も多いし結構骨が折れるかなと思います。 そこで、ガイドラインの公開を記念して、 ガイドラインのタイプやサーバーの種類を選んで、ボタンを押せば設定ファイルが 作れるようなツールを作ってみました。(ぱちぱちぱち)

HTTPS設定ファイル生成ツール0.2(ベータ版)
https://kjur.github.io/jsrsasign/tool/tool_httpscfg.html

今のところ、Apacheとnginxだけだったり、推奨設定の一部だけだったりするんですが、 プロトコルや暗号スイートなどは押さえているので、よかったら使ってみてください。

字は小さいですが、スマホブラウザでも設定ファイルが作れます。ぼちぼちアップデートして フル対応にしますので、乞うご期待ってことで。

あと、このツールの面白いのはCRYPTREC/IPAのガイドラインだけでなく、 MozillaやQualysなどの推奨設定や、Linux系OSのデフォルト設定も 試せるようになっている所です。暗号スイートの設定みてニヤニヤしていただければと、、、

今日はこの辺で、、、

(追記 2021.03.25) ツールのリンク切れを修正しました。

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 よりは、より具体的にどうすればよいかがわかるようになっています。最後の委員会が終わったあとも、リクエストがあったので追加原稿はいろいろ出させて頂いたんですが、どうも最終的に、特に暗号スイートの設定について、思った通りのものにはならなかったですね。いろんな意味で後悔しています。

今日はこの辺で

GoogleのCertificate Transparency (解説 [1] [2] [3]) のログデータベースはパブリックなHTTPSサイトに関する証明書のログデータベースなので、いろんな情報が取得できます。2015年3月27日時点で、6,949,166枚のSSLサーバー証明書に関する情報が格納されており、毎日1万枚以上増え続けています。これだけの枚数ですから、ここ数年有効な全世界のSSLサーバー証明書は網羅されているとして良いのかなと思います。以前紹介したgo.jpドメインのHTTPSサイトの調査もこの公開データをもとに調査しました。

本当は講演資料つくらないとマジでヤバイ感じなんですが、現実逃避して、ちょっと訳あってDSAやECDSA公開鍵のSSLサーバー証明書の利用、発行状況について調べてみたのでご報告を。そもそもはDSA公開鍵のSSLサーバー証明書を使っているDSSの暗号スイートなんて本当に使える公開サイトなんかあんのかって話を知りたかったわけです。

ほとんどの証明書はRSA公開鍵のSSLサーバー証明書であり、SSL Pulseの調査結果を見てもECDSAの証明書など割合からしてちょびっとな状況なわけですが、ログデータベースで見てみるとこんな感じです。(以下、2015年3月27日時点)

念のため補足しとくと、DSA公開鍵のSSLサーバー証明書とはSubjectPublicKeyInfoフィールドにDSA公開鍵が格納された証明書の事を意味し、これを発行する認証局の鍵のアルゴリズムはRSAでもDSAでもECC(ECDSA)でも何でも構いません。SSLサーバー証明書のSubjectPublicKeyInfoのアルゴリズムにより、SSL/TLSで通信した場合の暗号スイートの認証や鍵交換が決まり、DSA公開鍵の場合にはDSSの暗号スイートが使用されます。ECC(ECDSA)証明書についても同じような感じです。

DSA公開鍵のSSLサーバー証明書

100枚の証明書のうち、さらに実際に接続してみて現在も利用可能なサイトを調べてみました。

ちなみに、Firefox 36、Chrome 41 でこのDSA証明書のサイトへアクセスしてみると、以下のように表示され、暗号スイートとしてそもそもサポートしていなかったり、信頼するルートに入っていなかったりで接続できません。OpenSSLのs_clientコマンドで接続するしかないわけです。

ECDSA公開鍵のSSLサーバー証明書

ECDSA証明書については5%とそれなりに数はあるわけですが、 ちょっとドメインのリスト見てみると殆どcloudflaressl.comドメインばっかりなんですよ。

あ、そうそうGoogleでは*.google.comとかECCの公開鍵のSSLサーバー証明書を使っていてSSL/TLSで接続するとECDHE_ECDSAの暗号スイートになるんですが、その証明書の発行する認証局の鍵はRSAでSHA1withRSAで署名してるんですよね。「ChromeでSHA2移行をせかせる割には、お前はSHA1なんかいっっつ！！」みたいな。

おわりに

というわけで、全世界でどれくらいDSA証明書、ECDSA証明書が使われているのかを見てみました。結構興味深い事実もわかって個人的にはよかったかなと思います。オレはまだ本気出してないだけ。明日から講演資料作成頑張りまっすorz Certificate Transparencyについてはいろいろ深く突っ込んで調査しており、どこかで吐き出したいんですが、雑務に追われなかなかチャンスが無いなぁ。

慶応義塾大学とレピダムさんで共同調査された「日本政府機関Webサイト(.go.jp)のTLS対応状況について(2015.03.04)」を大変興味深く拝見し、もうちょっと知りたいことも多々あったので、私も調べてみるかなぁと思い、今日はそのご報告を、と。

調査対象

.go.jpドメインのサイトには省庁、外局、独立行政法人、政府系のイベントで作られたサイトなどがあり、そのうちパブリックなサイトのSSLサーバー証明書の枚数は2015年3月4日時点で累計1,819枚のようでした。そのうち、ユニークなコモンネーム(FQDNもしくはワイルドーカード証明書のドメイン)の数は877ありました。

省庁、それらの外局、それらが所管する独立行政法人の数で分類すると以下のような構成になっています。(実はこの表を作るのが一番大変だった。証明書はあるからFQDNはすぐに集まるんだけども、FQDNの独法や局や委員会なんかがどこの省庁が所管しているのかとか、イベントサイトはどこで管理されているかなどをGoogle先生やブラウザで開いたりなんかして、ちまちま調べるわけです。いや〜、独法っていっぱいあるんすねorz)

独立行政法人を除いたものの比率は以下のようになっていました。これには最高裁判所、内閣官房、会計検査院、国会図書館なども含まれています。

ワイルドカード証明書を使っている場合には、そのワイルドカード証明書を使っている任意の1つのサイトが見つかれば、そのサイトを調査対象としました。

イベントで一時的に立ち上がってたサイトや停止したサーバーなどがあり、インターネットからアクセス可能なgo.jpドメインのHTTPSサイトは882中、722であり、 今回は722のgo.jpドメインサイトを調査対象としました。

SSL/TLSプロトコル

まず最初に、go.jpドメインのサイトのSSL/TLSプロトコルのサポート状況を見てみたいと思います。ダウングレード攻撃やPOODLE攻撃で問題となるSSLv2、SSLv3をサポートしているサイトがかなりあることがわかります。まず最初に、全ての*.go.jpドメイン、つまり省庁と独法を合わせた接続可能な722サイトに対して、対応プロトコルをグラフにしました。

独法を除いた場合、333サイトが接続可能で、同様に対応プロトコルをグラフにしました。

ダウングレード攻撃で脆弱なSSLv2はかなり少ないですが、POODLE攻撃で脆弱とされるSSLv3が使えるサイトは未だに3、4割のサイトで利用可能になっていることがわかります。

暗号スイート(共通鍵暗号)

次に、暗号スイート(CipherSuite)のうち、使用可能な共通鍵暗号アルゴリズムについて見ていきましょう。最初に全*.go.jpドメインに対してです。

独法を除いた場合のグラフは以下の通りです。

どちらもAESはほとんどのサイトで利用できるようになっており、弱い暗号である3DESやRC4も8、9割のサイトで利用できるようになっています。また、国産の暗号であるCamelliaも2割程度のサイトで使えますが、SEEDやIDEAも同程度しかないというのは少し残念ですね。

ブロック暗号モードについては、GCMとCBCしかありませんが、全*.go.jpでのサポート状況は以下の通りになります。

また、独法を抜いた場合以下のようになります。

ブロック暗号を一切サポートせず、ストリーム暗号の暗号スイート、つまりRC4しかサポートしないサイトは無かったため、全数は722、333で同じになっています。

暗号スイート(鍵交換)

次に、暗号スイートで使われている鍵交換についてみてみましょう。

まず最初に気になるのが、スノーデンの暴露したNSAの盗聴問題をきっかけに、PFS(Perfect Forward Secrecy)をサポートする暗号スイートを使うことを推奨されるようになりました。 具体的にはDH、DHE、ECDH、ECHDEのいずれかを鍵交換に使う暗号スイートが推奨されています。 PFS、DH、DHE、ECDH、ECDHEの*.go.jpドメインでのサポート状況は以下の通りです。

独法を除いた場合、以下のようになります。

DHEやDHは処理パフォーマンスが悪かったり、長い鍵長をサポートする実装が少ないので、ECDHやECDHEを使えるようにして欲しいですね。

DH、DHEの暗号スイートで不十分な鍵長の脆弱なサイトが無いか確認するために、DHの鍵長別にサポート状況をみてみましょう。まずは全*go.jpドメインで見てみます。

独法を除いた場合、以下のようになります。

RSA 1024bit以下の証明書が使えなくなったのと同様にDiffie-Hellman(DH) 1024bit以下による鍵交換をするべきではないそうです。ただ、DH 1024bit以下しかサポートしない実装が多かったり、デフォルトでDH 1024bitであったりすることから、リスク回避のためにDHやDHEを使わないようにするのが良いと思います。

ECDH、ECDHEでは鍵パラメータ(=曲線名)はどうなっているでしょうか。まずは、全*.go.jpドメインで見てみましょう。

独法を除いた場合、以下のようになります。

ECDH、ECDHEをサポートする場合に、鍵交換で使われる名前付き曲線がNIST P-256(=secp256r1)なのは一般的だし、ブラウザでサポートされている事が多いのでいいですが、NIST B-571(=sect571r1)って世の中で使ってるところを見た事がなかったのでビックリしました。省庁の1サイトと独法の9サイトは先進的というか、デフォルトでは設定されず、意図的にやってるに決まってるので凄いなぁと思いました。そこにブラウザで繋いでみたんですが、TLS_RSA_WITH_RC4_128_SHAで接続してしまい残念orz。

暗号スイート(メッセージ認証(MAC))

世の中では、メッセージ認証に関してはMD5はダメ、SHA1からSHA2に移行している過程にあるのかなと思います。まず、全*.go.jpドメインについて見てみましょう。

独法を除いた場合、以下のようになります。

脆弱なHmacMD5を使った暗号スイートが利用できるサイトが4割近く残っているのは問題かなと思います。

SSL/TLS攻撃に脆弱なサイト

BEAST攻撃、POODLE攻撃、FREAK攻撃など、SSL/TLSプロトコルや暗号スイートの設定による脆弱性の影響をみてみましょう。全*.go.jpドメインでのこれらの攻撃の影響は以下のようになっています。 (少しグラフにゴミが入ったけど、まぁ、いっか)

独法を除いた場合、以下のようになります。

その他のSSL/TLSサーバーの設定

SSL/TLSでは接続する際、デフォルトではクライアントが提示する暗号スイートのリストの優先順位に基づいて、サーバーと使用する暗号スイートがされますが、これだと酷いクライアントの場合、脆弱な暗号スイートが使用されてしまう可能性があります。これを防止するために、設定によりサーバー側の持つリストを優先して使うようにすることができます。これが「サーバー側暗号スイート優先」です。ApacheであればSSLHonorCipherOrder "on"で設定できます。

OCSP Staplingとは、TLSの拡張でプライバシー保護と証明書失効検証の誤りへの対策です。 まずは全*go.jpドメインで見てみましょう。

独法を除いた場合、以下のようになります。

OCSP Staplingの導入はなかなか進んでいない現状がよくわかります。ただ、先進的な設定をしている政府系サイトもあることがわかります。

SSLサーバー証明書

全*.go.jpドメインのアクティブなサイトのサーバー証明書の発行元の 証明書発行サービスで分類したのが以下です。

独法を除いた場合、以下のようになります。

やはりVeriSignの比率がかなり高く、GPKI Application CA、GlobalSign、Cybertrustなども頑張っています。特に独法を除いたには、GPKI Application CA 2の比率もかなり高いです。 珍しい所ではServision、KAGOYA、Firstserver、AlphaSSLなどを使っているところもありました。 822枚のうちワイルドカード証明書は19枚、EV SSL証明書は24枚でした。

次に接続可能な全*.go.jp 723ドメインにおける、証明書の公開鍵アルゴリズムと鍵長についてみてみましょう。全てがRSA鍵であって、ECC鍵やDSA鍵はありませんでした。また、鍵長は2048bitがほとんどで、ほんの少し1024bitが残っており、4098bitなどの長いものはありませんでした。

また、723のRSA鍵について公開指数は全て65537(0x10001)でした。公開指数に3などが使われているために秘密鍵が入手できるといった問題があるサイトは0でした。

署名アルゴリズムについてはSHA256withRSA、SHA1withRSA、MD5withRSAのいずれかしかなく、SHA256withRSAの移行が30%以上とChromeやWindowsのSHA1の無効化が2017年1月に迫っていることから、SHA1からSHA2への移行はかなり進んでいます。

証明書の有効期間については、1年物、3年物、2年物の順に多く、10年物は1サイトのみでした。

Google Chromeが2017年1月までにSHA1証明書に対して段階的に警告を出していき、SHA2証明書への移行を促すというマイルストーンがアナウンスされていますが、有効期限がどの時期であるかを調べてみました。

有効期限が2017年1月を超える証明書が144サイトであり、Chromeでの警告表示を避けるためにSHA2証明書へのリプレースが必要になります。

また、証明書のOCSPによる失効検証、EV SSLサーバー証明書、Certificate Transparency(CT)のための組込みのSigned Certificate Timestamp(SCT)拡張のサポート状況について調べてみました。CTサポートが11サイトもあったのには、少し驚きました。

おわりに

以上、*.go.jp ドメインのHTTPSサイトについて自分なりに調査してみました。SSL Pulseとの状況と比較して、以下のポイントで若干コンサバティブというか古い設定になっているなという感じはします。

• GCMがあまり使われていない
• ECDHEよりもDHEが使われる
• EXP、DESなどの古い暗号スイートがかなり残っている
• SSLv2などもかなり残っている感じがする

今日はこの辺で。

追記

• 2015.03.11 08:34 - 3/4から3/11 0:00頃の更新を確認したらgo.jpドメインのHTTPSサイトは3つしか増えていないようです。そんなに頻繁に更新確認しなくてよさそうなので、ちょっと安心しました。現時点では証明書の調査項目が十分でないので、そのうち追加しておきたいと思います。
• 2015.03.12 00:11 - *.go.jpドメインのSSLサーバー証明書について調べた事を追記しました。
• 2015.03.12 07:55 - 証明書の調査でなぜ722から723に増えたかというと、HTTPS通信はできて証明書は取れるんだけど、対応暗号スイートを調べようとするとタイムアウトしちゃうサイトが一つあったため、こんなことになってます。

先週のInternet Week 2014でHTTPSサーバー設定のセッションのパネルパネルで言えなかった事の第二弾です。

自分のサイトが公開サイトである場合にはQualys SSLLabsのサイトを使って外部からSSLの暗号スイートの設定を確認すればよいんですが、イントラ内の場合には厄介ですよね。パケットキャプチャで調べるわけにもいかないし、OpenSSLのs_clientで暗号スイート一つ一つチクチク調べるのは面倒だし。

そんな時、クライアント側にWindowsが使えればwww.g-sec.luで公開しているsslauditというツールが便利です。

検査対象のサーバー(IPアドレスでも可)とポート(デフォルトでは443)を指定して、「Start」ボタンを押すだけです。利用可能なものだけを表示する場合には「Display supported ciphers」をチェックしてからスタートするとよいでしょう。

• SSLv2, SSLv3, TLSv1.0, TLSv1.1, TLSv1.2全てのプロトコルに対しプロトコル毎に サポートしている暗号スイートを調査
• 暗号スイートはGCM,ECDHE,SHA2など最新を含めかなり広範囲でサポートされており実用上問題にはならない。 (GOSTとかよっぽどマイナーなのは無かったと思う。)

関連リンク

• Internet Week 2014パネルで話しそびれたネタ: 統計情報でみるSSL/TLS
• Internet Week 2014パネルで話しそびれたネタ2: イントラ内でSSLサーバー設定を確認するツールsslaudit
• Internet Week 2014 S14 講演2「サーバの正しいSSL/TLS設定のツボ」補足情報ページ

いや〜、今年は脆弱性対策が当たり年ですね〜〜(トホホ)。 bash ShellShockの対策も継続して観察しているなか、 新しいPOODLEというSSLv3プロトコルに関する脆弱性が出てしまいました。 子犬のプードルだって！可愛くないっつ〜〜の！！ SSLv3プロトコルのパディングの問題点を突いて、効率的に暗号文を 復号できしまうので、例えばセッションクッキーを復号して通信を盗聴することが できるのだそうです。 POODLEはPadding Oracle On Downgraded Legacy Encryptionの略だそうで、 パディングオラクルとはパディングを含む暗号文を入力として送りつけると、 そのパティングが正しいかどうかを返してくれるブラックボックスのような 計算機のこと。 SSLv3みたいなできて15年にもなる弱い暗号通信プロトコルに、 強制的にダウングレードさせて、 オラクルに対して何回もいろいろ入力を変えて試行して、 エラーメッセージなどどう反応するかを見る事で、 暗号文の解読が効率良く行えるという攻撃です。

気がついたまでの経緯は当日どんな感じだったかというと、日本時間で10月14日の23:30頃、 The Registerの「NASTY SSL 3.0 vuln to be revealed soon」の記事を見つけていまい、こりゃ、やばげだなと。知り合いに明日ヤバイのがまた来そうと連絡しました。TLS 1.0とSSL 3.0とバージョン番号が違うだけだと言い張る人も多い中、Macとか、パディングとかそのちょっとの違いが仇になるんじゃないかと、ずっと気になってたんですが、とうとう来たかと。詳細情報は夜が明けないとわからないので、半分 wktk しながら寝て待ってたんですが、朝になって、Googleのブログ 「This POODLE bites: exploiting the SSL 3.0 fallback」が出てきたものの、わかったことはプードルという可愛らしい攻撃の名前と、GoogleサイトとChromeはとっくにTLS_FALLBACK_SCSVに対応しているぜ！みたいな。 自慢かっ？技術詳細なく自慢だけなのかっ！と憤りつつ、しばらく待ってると、 やっと安定のImperialVioletで 「POODLE attacks on SSLv3 (14 Oct 2014)」 技術解説が出たのを見て、こりゃマジやべ〜〜な、と・・・ その後、情報のとりまとめにいそしんでおりました。

この記事では、様々なHTTPSサーバーに対するPOODLE脆弱性対策の 方法について、まとめておきたいと思います。

古いガラケーや、一部のゲーム機や、古い環境でのAPI利用などを除いて、 一般のブラウザであればSSLv3でしか通信できないという事は無いので、 SSLv3を無効化するというのが、一番正当なPOODLE対策であると思います。 この章では、SSLv3を無効にするために、 サーバーのソフトウェア毎にどのように設定すればよいかをまとめます。

httpd.confやssl.confに

SSLProtocol All -SSLv2 -SSLv3

nss.confもしくはhttpd.confで

NSSProtocol TLSv1.0,TLSv1.1

ssl_protocols TLSv1 TLSv1.1 TLSv1.2

lighttpd 1.4.28 以降を使用。それ以前ではSSLv3を無効化できません。

ssl.use-sslv2 = "disable"
ssl.use-sslv3 = "disable"

コマンドラインで以下を実行することで、レジストリ設定により無効化します。 (参考 [1] [2] [3])

reg add "HKLM\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server" /v Enabled /t REG_DWORD /d 0 /f
reg add "HKLM\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server" /v Enabled /t REG_DWORD /d 0 /f

Tomcatの設定ファイル "server.xml"の"Connector"要素において、 Tomcatのバージョンに依存して、 sslEnabledProtocols属性もしくはprotocols属性に 使用するプロトコルをSSLv3を除いたTLSv1、TLSv1.1、TLSv1.2 を設定することにより、 SSLv3での接続を無効化することができます。 (参考 [4])

<Connector port="8443" protocol="HTTP/1.1"
  SSLEnabled="true" maxThreads="150" 
  scheme="https" secure="true"
  clientAuth="false"
  keystoreFile="/etc/tomcat/server.jks"
  keystorePass="password"
  sslProtocol="TLS"
  protocols="TLSv1,TLSv1.1,TLSv1.2"/>

<Connector port="8443" protocol="HTTP/1.1"
  SSLEnabled="true" maxThreads="150" 
  scheme="https" secure="true"
  clientAuth="false"
  keystoreFile="/etc/tomcat/server.jks"
  keystorePass="password"
  sslProtocol="TLS"
  sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2"/>

Tomcat同様これもインターネット直出ししている事はないと思いますが 以下の実装例のようにsecureOptionsでSSLv2,SSLv3を使用しないよう設定が可能です。 (参考 [6])

var constants = require('constants')
  , https = require('https')
  , path = require('path')
  , tls = require('tls')
  , fs = require('fs');
https.createServer({
  secureProtocol: 'SSLv23_method',
  secureOptions: (constants.SSL_OP_NO_SSLv3 | constants.SSL_OP_NO_SSLv2),
  cert: fs.readFileSync(path.join(__dirname, 'ssl', 'server.crt')),
  key: fs.readFileSync(path.join(__dirname, 'ssl', 'server.key')),
}, function (req, res) {
  res.end('works');
}).listen(443);

アドバイザリ が公開されています。httpd.confで以下のように設定し、サーバーを再起動します。

<VirtualHost *:443>
SSLEnable
SSLProtocolDisable SSLv2 SSLv3
その他の設定
</VirtualHost>

AWSから セキュリティアドバイザリが公開されており何度もアップデートされています。 利用するサービスによってそれぞれ対策が必要です。

その他のサーバーについては、以下を参考にしてみてください。

• ask ubuntu: How do I patch/workaround SSLv3 POODLE vulnerability (CVE--2014--3566)? - とても参考になります。Postfix SMTP, Sendmail, Dovecot, Courier-imap, HAProxy Server, OpenVPN, Puppetなど、特にメール関連サーバーはこちらを参考にしてみて下さい。

現在サポートされているPCやスマートフォンのブラウザではTLSv1.0以降 がサポートされているので問題にならないと思いますが、 例えば、2007年秋以前のdocomoのガラケーやSONY PS3では、SSLv3しかサポート していないことを実機で確認しています。 古いガラケー、ゲーム機、組込み機器に対応するウェブサーバーを 運用する場合には、接続できずクレームになる可能性もありますので、 クライアント側の対応環境を確認すると良いと思います。

また、ウェブサーバーをAPIで利用する場合にも、どのような環境、 言語実装を使うかで問題があるケースがありますので、 確認しておくと良いと思います。TwitterやFacebookも API利用されているためにトラブルになったそうです。

• しばやん雑記: Twitter や Facebook が SSL 3.0 を無効にしたので死にかけた話 (2014.10.15)

OpenLDAPについてはslapd.confを以下のように設定します。 (参考 [?])

バージョン 2.4.36以降の場合
TLSProtocolMin 3.1
バージョン 2.4.14〜2.4.35の場合
TLSProtocolMin 769

一般的なブラウザに関してはSSLv3を無効化する方向で進んでおり、 ウェブサイトでもSSLv3を無効化するのが、正しい対応だと思いますが、 古い環境をサポートしなければならないために、SSLv3を有効に しておかなければならないケースもあると思います。 3章では、SSLv3をサポートしなければならないケースでの、 脆弱性の緩和策について説明したいと思います。

POODLE脆弱性はSSLv3とブロック暗号のCBCブロックモードを使用した 場合に影響があるので、暗号スイートとして以下を選択することで 問題を緩和することができます。

• 認証付暗号化方式(AEAD)であるGCMブロックモードの暗号スイートを使用する
• ストリーム暗号(RC4,ChaChaなど)を使用する

RC4ストリーム暗号は、現実的な時間内に部分的に解読することが 可能な危殆化した暗号で使用すべきでないとされていますが、 POODLE脆弱性は適用条件や解読にかかる手間が極端に少ないので、 Triple DESをCBCモードで使うよりもRC4の方が、まだ安全であると 言えます。

• TLS_RSA_WITH_3DES_EDE_CBC_SHA を含む全ての暗号スイートを無効化
• その上で、TLS_RSA_WITH_RC4_128_SHA のみを有効化
• 同時に新しめのクライアントも環境もサポートしたいならGCMの暗号スイートを有効にする

ただし、マイクロソフト製品では2014年8月のアップデート以降、RC4は無効になっていますので、 Windows系のサーバー機を使用する場合には、Apacheなど他のサーバーを使う必要があるでしょう。

SSL/TLSで通信を開始した直後はTLSv1.0以上で問題ない接続であったとしても、 ある種の攻撃により脆弱なSSLv3.0以下にダウングレードさせる攻撃があります。

これを、防ぐための新しく提案されている仕組みが TLS_FALLBACK_SCSV オプションを使う方法です。これをサーバーとクライアントの双方が サポートする場合、TLSからSSLv3.0以下に強制ダウングレードさせることは できなくなります。

ただ、これをサポートしている環境は現時点(2014.10.18)では非常に限定的です。

• クライアント
  • Google Chromeのみ
• サーバー
  • 最新の2014.10.15リリースのOpenSSL 1.0.1j/1.0.0o/0.9.8zcを利用するApache,Nginx,Lighttpdなどのサーバー
  • Google提供のサービス(2014年2月頃からサポートしていたらしい)

• CBCブロック暗号モードをどうしても使う必要があり、
• TLSで最初接続できた利用者にはSSLv3ダウングレードせず安全に使用して欲しい。
• SSLv3で接続してきた利用者にはリスクを承知でCBCモードで接続してもらってもよい。

自分なりにケース毎の対応策(案)を整理してみました。よかったら参考にしてください。

表について、少し補足したいと思います。対策としては、SSLv3を無効にするのが基本的な対策となりますが、SSLv3を残しておく必要がある場合に、幾つかのケースに分類してみました。

一番良いのは、やはり(ケース2-1)のようにTLSv1.xのサーバーと、SSLv3のサーバーとを分ける事であるように思います。最近のウェブアプリケーションではHTML5、JavaScript、CSSなどリッチコンテンツが増えて、そうしたモダンなブラウザ向けのサービスと、SSLv3しかサポートしないサービスとを分けることで、互いに安全に利用することができます。

どうしても1台のサーバーでモダンなブラウザのユーザと、SSLv3のみにしか対応しないユーザに 対応する必要がある場合には、(ケース2-2)のように、CBCモードを使うことをあきらめ、モダンなブラウザユーザは TLSv1.xをGCMモードで接続することになり、GCMモードに対応できないユーザは、弱い暗号であるRC4のリスクを 受容して利用してもらうことになります。例えば、以下の順序で暗号スイートを設定するのが良いでしょう。

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_GCM_SHA384
• TLS_RSA_WITH_AES_128_GCM_SHA
• TLS_RSA_WITH_AES_256_GCM_SHA
• TLS_RSA_WITH_RC4_128_SHA

以上、SSLサーバーでPOODLE脆弱性対応をする方法について、いろいろなサーバー 毎にまとめてみました。参考になればうれしいです。今日は、こんなとこで。

SSLv3のパディングについては、いろいろ勉強したので、近いうちに記事にできるといいなと思っています。

• 2014.10.19 IBM HTTP Server, AWS, 対応策(案)の整理について追記しました。
• 2014.10.22 OpenLDAP ついて追記しました。
• 2014.10.28 Apache Tomcatの設定についてコメント頂きましたので、 実際に調査をし、 記述を修正しました。コメント頂きましたuraさん、takeshiさん、Youngdong.lee さん、ありがとうございました。

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の優先順位が微妙

今日はこの辺で

証明書ハンターであり、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です。今日はこの辺で