自堕落な技術者の日記

前にもお話した通り、 SSL Pulse (https://www.trustworthyinternet.org/ssl-pulse/)サイトは、 ssllabsでも有名なQualys社が運営しているサイトで、 Webサイト調査のAlexa社による 世界のアクセストップ20万サイトを対象にSSL関係の統計情報を毎月公開しています。 以前、2014年11月のSSL PulseでのSSL/TLSの状況推移をグラフ化しましたが、 2ヶ月たってどうなったのか、また今月もグラフ化してみました。

BEAST対応(CBC対応?)を除いて、全体的に順調に良くなる方向にあります。 悪い状態が上、良い状態が下になるようにグラフを統一したので、見やすくなったかと思いますが、どうですかね。

このあたりは、どれも普及が10%未満のままだと、、、

• SSL Pulseの統計情報で見るSSL/TLS (2015年1月版) (2015.01.25)
• Internet Week 2014パネルで話しそびれたネタ: 統計情報でみるSSL/TLS (2014.11.22)

先週の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設定のツボ」補足情報ページ

先週のInternet Week 2014でHTTPSサーバー設定の話をさせて頂きました。お越し頂いた方、ありがとうございました。マニアックな内容だったのですが、何か参考になる所があれば嬉しいです。

さて、今日はパネルネタで仕込んでおいたのに陽の目を見なかった話をちょっとブログで書こうと思います。SSL/TLS関連で統計データみたいなものを出しているサイトが幾つかあって、そこから世の中の傾向がわかったり、それを元に自分のサーバーはどう設定するかなぁ、などと考えるのに役に立つのではと思い紹介したいと思います。

SSL Pulse

まず最初に紹介したいのがSSL Pulseというサイトです。

出典：SSL Pulse https://www.trustworthyinternet.org/ssl-pulse/
このサイトSSL Pulse (https://www.trustworthyinternet.org/ssl-pulse/) はssllabsでも有名なQualys社が 運営しているサイトで、Webサイト調査のAlexa社による 世界のアクセストップ20万サイトを対象にSSL関係の統計情報を毎月公開しているもので、以下のような情報を公開しています。

• サーバー設定強度ランクA〜F
• プロトコルバージョン状況(SSLv3, TLSv1.2等)
• サーバー証明書の状況(SHA2対応、鍵長)
• 最近の脆弱性の対応率(HeartBleed, BEAST, CRIME, RC4等)

https://www.trustworthyinternet.org/asset/project/ssl-pulse/data/index.json
https://www.trustworthyinternet.org/asset/project/ssl-pulse/data/ssl-pulse_2014-11.json

SSL Pulse: SSLプロトコルバージョン推移

これは、2012年4月からのSSL/TLSのプロトコルバージョンの推移です。

• ずっとSSLv3、TLSv1.0はほぼ100%のサポートだったが、 2014年10月に発見されたPOODLE攻撃の影響でSSLv3が60%にまで下がった。
• TLSv1.1、TLSv1.2は順調にのびているが、まだ50%程度しかない。
• SSLv2を使っているサイトが、未だ20%近くある。

SSL Pulse: SSL脆弱性の対応推移

今年はSSL/TLSに関しても脆弱性の当たり年でしたが、脆弱性への対応の推移をまとめてみました。 元データのせいで評価の仕方が「対応してる率」なのか「してない率」なのかバラバラで、本当は統一できればよかったんですが、わかりにくくてすみません。

• HeartBleedについては重大な問題だったためか発生直後で大多数が対応しているようだ。
• CCSInjectionについても対応率が高いが影響自体が少なかったせいかもしれない。
• 再ネゴシエーション攻撃についても対応率が高く残り数%の所まできている。
• CRIME、TIMEなどSSL圧縮による攻撃の影響を受けるSSL圧縮を無効化していない サイトも数%までに現象した。
• スノーデンの告白でわかったNSAなどの大量監視から身を守る Perfect Forward Secrecy対応のため、ECDHE、DHEの暗号スイートを使えないサイトは 40%程度まで減ってきており対応がかなり進んだ。
• ストリーム暗号RC4の危殆化と、Microsoft製品がRC4アルゴリズムの利用を 無効化した影響か、RC4アルゴリズムを使えないサイトが20%ぐらいと徐々に 増えているが未だRC4を使えるサイトは80%もある。
• BEAST、BREACH、POODLE攻撃などに影響のあるCBCブロック暗号モードを 利用可能なサイトは一時現象傾向を見せたが、RC4停止と逆にCBCが増えており、 CBCの利用可能は80%近くまで戻している。レガシー環境では暗号スイートは 3DES-CBCかRC4の2択しかないが、Microsoftが利用停止した影響もあり、 BEAST攻撃対策をあきらめてRC4対策を取るという傾向にあるようだ。

SSL Pulse: サーバー証明書の署名アルゴリズム推移

Microsoft や Google のブラウザが、SHA1withRSA署名アルゴリズムの証明書のサポートを2017年1月には打ち切るとしており、サーバー管理者の方はSHA256withRSAなどの証明書の移行をそろそろ検討しなければならないかと思います。 サイバートラスト社のサイトでMicrosoft、Google、Firefox、CABForumのSHA1証明書対応をとてもわかりやすくまとめておられるのでご覧になると良いと思います。 では、署名アルゴリズムの移行についても見てみましょう。

• 2014年6月以降、90%→75%と急激にSHA1withRSA証明書が減っている。
• 逆にSHA256withRSA証明書は10%→25%と急激に増えている。
• SHA256withECDSA証明書はなかなか利用がすすまずほぼ0%で横ばい。

SSL Pulse: SSLの先進機能の利用推移

EV証明書が先進機能かどうかはさておき、HTTPS関係の先進機能の利用状況推移について見てみましょう。

• 先進機能はどれも10%に満たない。
• EV証明書も増えてはいるが2年で8%→10%と微増
• SPDYサポートも6%程度
• 通信をHTTPS強制化するHSTS(HTTP Strict Transport Security) もわずか2%で増えているという感じでもない

SANS SSL CRL Activity

セキュリティ教育機関であるSANS Instituteの SSL CRL Activity (https://isc.sans.edu/crls.html) というページで、サイトを閉鎖する時とか鍵が盗まれたなどでSSLサーバー証明書を失効させた場合の失効件数を、全ての認証局について毎日集計をして、公表しています。大きな攻撃があった時や、認証局に何らかの問題があった時に大量の失効が発生することがあります。2002年からと、かなり昔から情報収集をしています。

表示する期間を好きなように設定して表示させることができます。

まずは、2002年から現在までの失効数推移をみてみましょう。

2014年に突如70,000件もの大量失効があったのはHeartBleed脆弱性の問題の影響です。では、それまでの 推移をみてみましょう。HeartBleed脆弱性の前は、概ね単純に増加しているのみであり、SSLサーバー証明書の利用者も順調にのびており、1日千件程度の失効になってきていました。

大量失効の前後を中心にみてみると以下のようになっています。

GlobalSignが2014年4月16日、17日、証明書を大量失効させたのが一因のようです。HeartBleed後はCCSInjectionやPOODLEの影響と思われる失効のピークが見られます。

ChromeのHTTPS通信の比率の推移

おわりに

以上、Internet Weekのパネルで紹介しようかなぁと思ったけどボツになったネタを紹介させていただきました。こりゃ、話はじめると長い話になっちゃうので、パネルで触れなくて結局は正解だったんですかね。グラフにしてみると何がどんな風に変化しているのかわかって楽しいですよね。今日はこんなところでw

関連リンク

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

先日の記事のコメント欄に Apache TomcatでもSSL/TLSのプロトコルバージョンを指定できると 教えて頂き、どのバージョンはどの設定なの？みたいな話が、 Google先生に聞いてもよくわからなかったので、 幾つかのバージョンのTomcatを取り出してプロトコルバージョンの設定 方法を確認してみました。

具体的には、Oracle J2SE JDKの1.7.0_71で、 いろいろなバージョンのTomcatについて、 openssl s_clientコマンドでプロトコルバージョンを指定しながら 確認していきます。 それぞれの確認結果はこんな感じ。

6.0.37までのprotocols属性はマニュアルには書かれていない 隠し属性だったみたいですね。6.0.39からなんでパタッと変えたんですかねぇ。 普通なら後方互換性を持たせてprotocolsとsslEnabledProtocolsの両方を 使えるようにすればいいのに、ばっさり、protocolsを切っちゃうのはどうだったんですかねぇ。 せめて6.0.xでは一貫してprotocolsを使うようにした方がよかったんじゃないですかねぇ？

いや〜、今年は脆弱性対策が当たり年ですね〜〜(トホホ)。 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 さん、ありがとうございました。

SHA1withなんとかで署名されたSSLサーバー証明書に対するGoogle Chromeの 将来の取扱いポリシについて、Googleのブログで9月5日に情報公開され、ちょっとビックリした人も多いんじゃないでしょうか。私は、「こりゃちょっと問題だなぁ。」と思ったので今日はブログで書いてみようと思います。

SHA1が充分な暗号強度がなくなりつつある話

暗号の専門家ではないので、よくわからないのですが、 例えばコレなんかをみてみるとSHA1ハッシュアルゴリズムの暗号強度が充分でなくなってきていると言われており、暗号に関する日本で主要なガイドラインであるCRYPTREC暗号リストではSHA1は「運用監視暗号リスト」、危殆化リスクが高まっているが互換性維持のため仕方なく使って良いリストに入っています。

このような状況を受けて、製品ベンダー、証明書発行サービスなどのサービサーなどはSHA1からSHA2への移行をようやく始めたところなのかなと思います。

米国の標準化機関であるNISTは2011年1月に「NIST SP 800-131A Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lenghs(暗号アルゴリズムと鍵長の使用に関する勧告)」を発行しており、その中で「SHA1を使った署名の生成と検証は2013年12月31日以降、認められない。」としていますが、NIST内でもSHA1証明書を使ったサイトがまだ残っているそうで、「自分も守れてないじゃ〜〜ん」みたいな状態になっているそうです。

2013年11発表のMicrosoft製品のSHA1移行ポリシー

幾つかの業界や製品では先行してSHA1からの移行ポリシーを策定、公表しているものもありますが、SSLサーバー証明書に関しては幅広い製品やサービスで使われ、SHA1を使っている比率も高く移行は難しいのだろうと思います。本来ならCA Browser ForumのBaseline Profileで規定されてもよかったのだろうと思いますが、SHA1からの移行については言及されていません。 そんな中、2013年11月12日に発表されたMicrosoft製品に関して公開された2つのSHA1移行ポリシーはちょっと衝撃的でした。

Windows Root Certificate Program - Technical Requirements version 2.0

このプログラムはWindows製品の「ルート証明書プログラム」という、Windowsの信頼するルート証明書に加えてもらうためには、どのような基準を満たさなければならないかを定めたものですが、「対象の認証局は2016年1月1日以降、SHA1証明書を発行をしてはならない。」としています。

Windows PKI Blog: SHA1 Deprecation Policy

「Windows製品では2017年1月1日以降、SHA1のSSLサーバー証明書を受理しないためエラーとなる。」としています。すなわち、Windows製品でSSLを使えるようにするには、SHA1 SSLサーバー証明書を2016年12月31日までにSHA2にリプレースしなければならないという事だそうです。

これに関して注目すべきポイントは以下の2つかと思います。

• 中間CA証明書やルート証明書のSHA1については言及していない。
• 2016年1月1日と、2017年1月1日という2つのマイルストーンを守りさえすればよい。

• シマンテック社： ハッシュアルゴリズムのSHA-1からSHA-2への移行に関して
• グローバルサイン社：SHA-2電子証明書への移行について

2014年9月5日に公開されたGoogle ChromeのSHA1 証明書対応ポリシー

2014年9月5日に「Google Online Security Blog: Gradually sunsetting SHA-1」 にて、Google ChromeのSHA-1証明書にするポリシーの変更が発表され、一部の人は驚きを持って読んだのではないかと思います。 ITmediaエンタープライズでも 「Google、「SHA-1」サポート中止のスケジュールを発表(2014.09.08)」 として紹介されました。(何点か間違いがあるので、原文を参照するのがいいでしょう。)

これは簡単に言ってしまうと、「SHA-1のSSLサーバー証明書によってHTTPSの接続表示を近々(大きく)変えますよ」というアナウンスです。

Google ChromeのHTTPSステータス表示

Google ChromeのアドレスバーにおけるHTTPSのステータス表示は以下のようになっているようです。

表示	内容
	EV証明書でない正常なHTTPS接続の場合
	secure, but with minor errors 例えばHTTPSとHTTPのコンテンツの混在の場合などに出る。
	neutral, lacking security 平文のHTTPなど、セキュリティが無い中立の状態。
	affirmatively insecure 危険だと断言できる場合。
(参考) EV SSLサーバー証明書で正常にHTTPS接続できている場合

Google Chromeは証明書チェーンがSHA1かどうかチェック

WindowsのSHA1移行ポリシーはエンドエンティ証明書、すなわちSSLサーバー証明書がSHA1かどうかだけをチェックしており、中間CA証明書がSHA1かどうかは関係無かったのですが、Google Chromeの移行ポリシーは、全ての中間CA証明書もチェックするので注意しなければなりません。

で、ChromeでSHA1証明書でHTTPS接続した場合どうなるのか？

9月5日に発表された、ChromeでSHA1証明書にHTTPS接続した場合のURLアドレスバーのHTTPSステータス表示が、この半年で3回出てくるChromeのバージョンによって、どう変わっていくのかを整理したのが下の表です。

	Chrome 39 開発版の途中まで 〜2014.09.26 38安定版まで (〜2014.11上旬)	Chrome 39 開発版の途中から (2014.09.26〜 2014.11.09) 39安定版 リリースから (2014.11上旬〜	Chrome 40 開発版の途中から (2014.11.09〜 2015.Q1) 40安定版 リリースから (2015.01?〜	Chrome 41 開発版の途中から (2015.Q1〜 2016.12.31) 41安定版 リリースから (2015.03?〜	2017.01.01〜
有効期限が2016年5月31日までのSHA1証明書
有効期限が2016年6月1日から12月31日までのSHA1証明書
有効期限が2017年1月1日以降のSHA1証明書
Windowsの場合(Chrome同等の表示として)

今回のChromeのSHA1対応ポリシの問題点

今回のGoogle ChromeのSHA1証明書に対する対応計画は様々な問題があると考えていて、論点を整理したいと思います。

• 最も重要だと思うのが、ブラウザ毎にHTTPSのエラーや問題に対する表示の意味が異なってしまうという点です。今回のSHA1証明書の表示の計画がブラウザベンダー毎に異なるのはユーザが混乱することになり、良くなかったと思います。本来ならCA Browser ForumのBaseline Profileなどで、業界で意思統一されたSHA1証明書の移行計画を示し、EV証明書のように準拠するブラウザは同じようなステータス表示にするべきだったと思います。
• 2つの有効期限の異なる証明書があって、その有効期限により表示状態が異なるということは問題です。 今回はSHA1署名アルゴリズムの暗号危殆化を問題に取り上げているのですから、有効期限の長短にかかわらず、ある時点での暗号危殆化の程度は全く同じであり、同じものに対しては同一のHTTPSステータス表示にすべきではないでしょうか。
  
  
• 2017年1月1日からを、SHA1証明書を使ってはならない日と定めたとして、2年3ヶ月以上も前にユーザに表示を変えて伝える必要があるのでしょうか。2017年1月1日まではSHA1証明書を使って良いとするなら、いかなる警告もそのことで出す必要がなく、これはユーザも、ウェブサイト運営者も混乱させるだけです。2年以上も前に表示が異なってしまうことで、ユーザはサイトへクレームや問い合わせを入れるようになり、ウェブサイト管理者は仕方なく2年前倒しでSHA2証明書への移行を迫られることになります。
• 最近のモダンなブラウザではSHA2証明書に対応していますが、古いJavaや、組込み機器、ICカード、ガラケー(フィーチャーフォン)などSHA2証明書に対応できない環境は、未だに多数あります。これらの環境と歩調をあわせながらSSLサーバー証明書のSHA2移行を進める必要があったのではないでしょうか。
• 前述のOSなどのレベルでアルゴリズムとしてSHA2署名をサポートしていたとしても、検証などで使おうとするSHA2証明書のトラストアンカとなるルート証明書が「信頼するルート証明書」ストアに入っているかどうかは別の問題。例えば全てのお客様や、全社員のWindows XP SP3に対してルート証明書を追加させるという事はかなり困難。
• Netcraftの2014年5月の調査によれば、 インターネット上のウェブサイトのうち92%がSHA1証明書のままであり、SHA2証明書へ移行済なのはわずか7%にすぎません。HeartBleed脆弱性の影響で証明書のリプレースが多くあったため、SHA2への移行は進んだようですが、それでもたった7%です。このような状況で2014年9月にはHTTPSステータス表示を変えるというのは急すぎないでしょうか。(追記 SSLPulseによると2014年9月時点でSHA2は15%だそう)
• SHA1証明書に対する表示変更のポリシーを2014年9月5日にアナウンスしてから、わずか21日後の2014年9月26日の開発版アップデート、安定版では2014年11月頃の39リリースで、影響を受けるサイトが出始めます。充分な猶予期間、準備期間を持てるように例えば半年や1年といったスパンで事前アナウンスをする必要があったのではないでしょうか。
• SSLサーバー証明書は一般に2年や1年といった有効期間のものを購入される組織が多いと思いますが、例えば2014年6月1日から、アナウンスのあった2014年9月5日に2年物のSHA1証明書を購入し設定したウェブサイトは、早速2015年の1Qには、問題があるかのような黄色表示 になります。事前に知らされていれば、1年物を買うとかSHA2証明書を買うとか対策ができたかもしれません。 これは、あまりに不親切でユーザやサイト管理者の事を考えていない行為だと思います。
• 2017年1月1日以降が有効期限であるSHA1証明書が、2017年1月1日以降は使えなくなるという事は理解できるとして、2016年6月1日から2016年12月31日の間に有効期限がある証明書を分けてアラート表示をする必要があるとは思えません。

参考にすべきページ

今回のChromeのSHA1移行について問題提起や対策などを示している良いページがあるので、紹介しておきたいと思います。

CSO Online: Do you agree with Google's tactics to speed adoption of SHA-2 certificates?

CA Security Councilの中の人の問題提起。オンラインショップクリスマス商戦の時にこのような問題を起こすのや良くないとも言っている。Windows Server 2003ではhotfixなしでは非対応だと。他にも参考になるアドバイスがある。意見も募集している。

BLOG: IVAN RISTIC: SHA1 deprecation: what you need to know (2014.09.09)

SSLの状態を調べられるQualysのSSLLabsを作っていたり、SSLの設定ガイドなどを書いているIvanさんのページで、今回のGoogle Chrome SHA1移行について、どのように対処するのが良いか解説しています。いつも冷静な分析をされる人ですが、今回に関し批評が無いのは寂しい。

CA Security Council: List of Operating Systems, Browsers, and Servers Which Support SHA-256 Hashes in SSL Certificates (last update Sep 8, 2014)

最新のSHA-256サポート状況のリストです。参考になります。でも、OSや環境レベルでSHA2をサポートしたと言っても、これから使おうとしているSHA2証明書のトラストアンカとなるルート証明書が信頼するルート証明書ストアに入っているかは別の問題。

おわりに

Google Chromeは良いブラウザだと思うし、便利だし、大好きなんですが、CRLSetの問題と、今回のSHA1対応の件はちょっとヒドイなぁと思います。サイトの運営者の方は、最初のマイルストーンの9月26日まで、あまり余裕がないので、至急自分の環境を調査して対策を取った方がいいと思います。今日はこんなところで。

本ブログの関連記事

• 将来Google ChromeがSSL証明書のオンライン失効検証をやめて独自の失効情報プッシュを行うという困った話(2012.02.13)
• Windows Server 2003とSHA2証明書(2008.08.24) - コメントにhotfix

関連リンク

Mozilla Security Blog: Phasing Out Certificates with SHA-1 based Signature Algorithms (2014.09.23)

Mozilla Firefoxからも同様のSHA1移行ポリシーが公開されました。

(訂正)バージョン番号の修正(2014.09.17)

バージョン38が既にリリースされていると勘違いして、 今回のSHA1アラート表示の修正が、マイナーで入るのかと勘違いしたため表の バージョンの表記がおかしくなっていましたので修正しました。 バージョンの確認はこちらでできるようになっており、直近のメジャーですと以下のようなリリース履歴であるとわかりました。すみませんでした。(影響日やバージョンについて再修正しました9/17 12:50)

• 安定版メジャー 37.0.2062.94 2014.08.26 for Win,Mac,Linux
• 安定版メジャー 36.0.1985.125 2014.07.16 for Win,Mac,Linux
• 安定版メジャー 35.0.1916.114 2014.05.20 for Win,Mac,Linux
• 安定版メジャー 34.0.1847.116 2014.04.08 for Win,Mac,Linux

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/

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

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

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

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

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

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など弱い暗号もサポート

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の魚拓を 取っとかなかったことです。自動的に情報収集する仕組みを作るかなぁ・・・

今日はこのへんで

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

今日はこの辺で

CRLについて

• Digicert Sdnの問題を指摘された2つの中間CAは、 発行した証明書にCRL配布点(CDP)拡張は無いんだけども、 CRL自体はきちんと3日おきに発行しているようです。
• Entrustは、 Digicert Sdnの中間CAを少し移行までの猶予期間を持たせ 11月8日かそれより前に失効させると声明しています。 現時点(11月7日18:50 JST)では失効されていません。
• GTE CyberTrust Global Root(Verizon)は 失効させるといった声明はありません。 現時点(11月7日18:50 JST)では失効されていません。

Mozilla(FireFox)の認証局ブラックリスト追加のソースコードの更新

Mozillaでは前回のDigiNotarの証明書をブラックリストに入れる際、 certdata.txt に証明書を登録し、これからコード certdata.c を自動生成しています。

http://mxr.mozilla.org/mozilla/source/security/nss/lib/ckfw/builtins/certdata.txt

以上、ちょっと補足でした。アップデートがあれば、また書きます。

関連記事

• 2011.11.06 米ユタのDigiCertとは無関係なマレーシアのDigicert Sdn認証局の問題について見てみたぞ

2011年11月3日のニュース でマレーシアのDigicert Sdn. Bhd.社という認証局が問題のある証明書を発行しており

• 現在、解読が可能とされている512bitのRSA鍵の証明書を発行している
• SSLサーバー証明書として使うには証明書の拡張領域に問題があった
• マレーシア政府機関に発行したものにも512bitの弱い鍵が使われている
• 発行した22枚の証明書で512bit鍵が使われている

• MicrosoftやMozillaが問題のあったマレーシアのDigicert Sdnの中間証明書を ブラックリストに入れた。FireFoxでは8からの対応になる。
• Digicert Sdnの上位のルート認証局であるEntrust社は問題のある中間証明書を、少し移行までの猶予を持たせ11月8日かそれより前に失効させる

最初、ツイッターなどでこの問題が紹介されたとき米ユタ州にある割と 有名な認証局Digicertの子会社が問題が起こしたのかと 勘違いされていたようですが、全く別のマレーシアの会社だったようで 米DigiCert社も声明を出しています。 米DigiCert社は先日のオランダのDigiNotar社の時も 名前が似てたため「うちは関係ないよ」と声明だしており、最近踏んだり蹴ったりですねw。 さて、今日はこのマレーシアのDigicert Sdn認証局について、 ちょっと見てみたので報告したいと思います。

マレーシアDigicert Sdn社の幾つかの認証局

マレーシアのDigicert Sdn社はルート、中間を含め(おそらく)13もの認証局を持っています。我々に危険性の影響があるのは図の左側、多くのブラウザに信頼するルート認証局として搭載されている EntrustとGTE CyberTrust(現Verizon)をルート認証局とする 2つの中間認証局です。

Digicert社のそれぞれの認証局の特徴などを下表にまとめてみました。

• CIMB Investment Bank Berhad Enterprise CA
• Bank Negara Malaysia Sub CA

EntrustとGTE CyberTrustルートのDigicert Sdn中間認証局

マレーシアのDigicert Sdnのルート証明書はIEやFireFoxなどの ルート証明書には搭載されておらず、 今回、Microsoft や Mozillaがブラックリストに入れたのは EntrustやGTE CyberTrustをルート認証局とするDigicert Sdnの 中間CA証明書です。 IEでみるとGTE CyberTrustルートの場合、証明書チェーンはこんな感じ、

IEでみるとEntrustルートの場合、証明書チェーンはこんな感じです。

両者を少し数字で比較してみましょう。

現在、解読された実績のある512bit RSA鍵の証明書を発行している ことは問題といえば問題ですが、利用者が鍵を生成して 証明書発行要求しているわけですから利用者側にも問題がありますよね。

問題のある証明書拡張領域とは？

拡張領域の違いはGTE CyberTrustルートとEntrustルートでは なくて、鍵長により微妙に拡張が違うようです。 これは鍵長2048bitのもの。

これは512bitのものです。

ニュースでは、通常TLSサーバー用とか TLSクライアント用とか書かれる 拡張鍵使用目的(Extended Key Usage)がないとか、他にも 拡張でおかしなところがあると言っています。 おかしなところをヤバい順にまとめてみましょう。

CRL配布点(CDP:CRL Distribution Points)が無い

これが無いため証明書を失効させることができません。 今回のように発行した証明書に問題があった時に失効できないことはホント致命的。

KeyUsageがないものがある

512bit RSA鍵の場合に拡張が無いようです。 RFC 3280的にはTLSでは署名検証に使うので必須(MUST)ですね。

拡張鍵使用目的(EKU:Extended Key Usage)がない

必須ではなかった気がしますが普通ついてます。

KeyUsageがあっても、不要なビットが立っている

Key Usage拡張は512bitより大きい鍵の証明書では有るようですが、 値としてDigital Signature、Non-Repudiation、Key Encipherment、 Data Enciphermentのビットが立っています。 SSLサーバー証明書ではNon-Repudiation、Data Enciphermentは余計ですよね。

RFC 5280 4.2.1.12 Extended Key Usageより
If a certificate contains both a key usage extension and an extended key usage extension, then both extensions MUST be processed independently and the certificate MUST only be used for a purpose consistent with both extensions.
中略
id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 }
-- TLS WWW server authentication
-- Key usage bits that may be consistent: digitalSignature,
-- keyEncipherment or keyAgreement

RFC 5280ではExtended Key UsageとKey Usageが一貫している 事がMUSTになっています。

基本制約(Basic Constraints)が無い

なければ認証局証明書でないってことなんですが、一般にはつけることが多いですよね。 随分昔、あるメーラーで基本制約が無いことを無視して、ユーザ証明書から下位証明書発行しても検証成功だったことを発見してしまったり、、、

Authority/Subject Key Identifierで64bitは最近珍しい

ですよね？

CPS(認証実施規程)と照らしてどうなの？

認証局ではCPS(認証実施規程)で定めた運用に従い 証明書を発行するわけですが、これと照らしてどうだったのか Digicert SdnのCPSを ちょっと見てみました。

• 鍵長が512bit以下ではダメだという記述は見当たらなかったので CPS的に512bitの鍵に対して証明書発行することは問題が無かったようだ。
• 拡張領域については単に使用可能な拡張をまとめているだけで 発行する証明書の用途ごとに証明書プロファイルを定めて いなかったのでCDP拡張など拡張が不足していたり問題があったと してもCPS違反になることは無い。

ただ、CPS中の証明書プロファイルについて、どのような拡張が 必ず含まれるのか、含まれないのか明確になっておらず、 CRL配布点拡張が無いという認証局設計上の重大な欠陥が 明らかになってこなかったという問題はありますけどね。

今回の問題に対する評価はこれでいいのか

今回の問題は、COMODOやDigiNotarのように攻撃されて サブCAやRAが乗っ取られ不正な証明書を出し放題になっていたわけでも なく、同列に問題を語られているのは違和感を覚えます。 高々、認証局ではなくSSLサーバ証明書の鍵が不正に使われるだけですよね。 512bit鍵の証明書を発行してしまったのは、利用者(お客さん)にも 問題があったわけですよね。 とても悔やまれるのはCRL Distribution Points拡張が 入っていなかったその一点です。 それさえ入っていれば、問題が発覚しても 単に証明書再発行すれば済んだのに、 中間CA証明書のブラックリスト入りという結果になってしまいました。 同じCAから発行されているSSLサーバー証明書でも 拡張のまともなものもあり

完全にとばっちりを食ったお客さんも多数いるわけですよね。 可哀想だなぁと思います。

GTE CyberTrust Global Rootを運用しているVerizonからは 何のコメントも無いのも変な感じですよね。

おわりに

以上、マレーシアのDigicert Sdnの認証局の問題について ちょっと調べたところを報告しまいた。 512 bit RSA鍵が問題だみたいなニュースの論調ですが、 あれはユーザの鍵なのでCA鍵と違って危殆化しても大した問題では なくて、それよりもCRL配布点拡張が無いことにより失効の手立てがなく、 中間CA自体を廃棄するしか手が無かったってことが問題だったわけです。

やべやべ、夜更かししちゃったよ。 ではでは、、、

関連リンク

• threat post 2011.11.03: Malaysian CA Digicert Revokes Certs With Weak Keys, Mozilla Moves to Revoke Trust
• SOPHOS Naked Security 2011.11.03: Another certificate authority issues dangerous certficates
• (マレーシアの)digicert Certification Authority
  • 本件のお知らせ
  • CRLリポジトリ
• 米ユタ州のDigiCert - DigiCert, Inc. Of No Relation to Recent "Digi" Insecure Certificates
• Entrust - Entrust Bulletin on Certificates Issued with Weak 512-bit RSA Keys by Digicert Malaysia
• ITmediaニュース 2011.11.04 SSL認証局問題が再び発覚、MicrosoftとMozillaが対応表明 今度はマレーシアのSSL認証局が発行した証明書に問題が発覚した
• InfoWorld SECURITY CENTRAL 2011.11.04 Mozilla, Microsoft withdraw trust in Digicert certificates