自堕落な技術者の日記 : go.jpドメインのHTTPSサイトの状況について私もみてみました(2015年3月4日時点)

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

調査対象

.go.jpドメインのサイトには省庁、外局、独立行政法人、政府系のイベントで作られたサイトなどがあり、そのうちパブリックなサイトのSSLサーバー証明書の枚数は2015年3月4日時点で累計1,819枚のようでした。そのうち、ユニークなコモンネーム(FQDNもしくはワイルドーカード証明書のドメイン)の数は877ありました。
gojp-01
省庁、それらの外局、それらが所管する独立行政法人の数で分類すると以下のような構成になっています。(実はこの表を作るのが一番大変だった。証明書はあるからFQDNはすぐに集まるんだけども、FQDNの独法や局や委員会なんかがどこの省庁が所管しているのかとか、イベントサイトはどこで管理されているかなどをGoogle先生やブラウザで開いたりなんかして、ちまちま調べるわけです。いや～、独法っていっぱいあるんすねorz)
gojp-02
独立行政法人を除いたものの比率は以下のようになっていました。これには最高裁判所、内閣官房、会計検査院、国会図書館なども含まれています。
gojp-03

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

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

SSL/TLSプロトコル

まず最初に、go.jpドメインのサイトのSSL/TLSプロトコルのサポート状況を見てみたいと思います。ダウングレード攻撃やPOODLE攻撃で問題となるSSLv2、SSLv3をサポートしているサイトがかなりあることがわかります。まず最初に、全ての*.go.jpドメイン、つまり省庁と独法を合わせた接続可能な722サイトに対して、対応プロトコルをグラフにしました。
gojpa-1
独法を除いた場合、333サイトが接続可能で、同様に対応プロトコルをグラフにしました。
gojpa-2
ダウングレード攻撃で脆弱なSSLv2はかなり少ないですが、POODLE攻撃で脆弱とされるSSLv3が使えるサイトは未だに3、4割のサイトで利用可能になっていることがわかります。

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

次に、暗号スイート(CipherSuite)のうち、使用可能な共通鍵暗号アルゴリズムについて見ていきましょう。最初に全*.go.jpドメインに対してです。
gojpa-3
独法を除いた場合のグラフは以下の通りです。
gojpa-4
どちらもAESはほとんどのサイトで利用できるようになっており、弱い暗号である3DESやRC4も8、9割のサイトで利用できるようになっています。また、国産の暗号であるCamelliaも2割程度のサイトで使えますが、SEEDやIDEAも同程度しかないというのは少し残念ですね。

ブロック暗号モードについては、GCMとCBCしかありませんが、全*.go.jpでのサポート状況は以下の通りになります。
gojpa-5
また、独法を抜いた場合以下のようになります。
gojpa-6
ブロック暗号を一切サポートせず、ストリーム暗号の暗号スイート、つまりRC4しかサポートしないサイトは無かったため、全数は722、333で同じになっています。

暗号スイート(鍵交換)

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

まず最初に気になるのが、スノーデンの暴露したNSAの盗聴問題をきっかけに、PFS(Perfect Forward Secrecy)をサポートする暗号スイートを使うことを推奨されるようになりました。具体的にはDH、DHE、ECDH、ECHDEのいずれかを鍵交換に使う暗号スイートが推奨されています。 PFS、DH、DHE、ECDH、ECDHEの*.go.jpドメインでのサポート状況は以下の通りです。
gojpa-7
独法を除いた場合、以下のようになります。
gojpa-8
DHEやDHは処理パフォーマンスが悪かったり、長い鍵長をサポートする実装が少ないので、ECDHやECDHEを使えるようにして欲しいですね。

DH、DHEの暗号スイートで不十分な鍵長の脆弱なサイトが無いか確認するために、DHの鍵長別にサポート状況をみてみましょう。まずは全*go.jpドメインで見てみます。
gojpb-01
独法を除いた場合、以下のようになります。
gojpb-02
RSA 1024bit以下の証明書が使えなくなったのと同様にDiffie-Hellman(DH) 1024bit以下による鍵交換をするべきではないそうです。ただ、DH 1024bit以下しかサポートしない実装が多かったり、デフォルトでDH 1024bitであったりすることから、リスク回避のためにDHやDHEを使わないようにするのが良いと思います。

ECDH、ECDHEでは鍵パラメータ(=曲線名)はどうなっているでしょうか。まずは、全*.go.jpドメインで見てみましょう。
gojpb-03
独法を除いた場合、以下のようになります。
gojpb-04
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ドメインについて見てみましょう。
gojpb-05
独法を除いた場合、以下のようになります。
gojpb-06
脆弱なHmacMD5を使った暗号スイートが利用できるサイトが4割近く残っているのは問題かなと思います。

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

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

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

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

OCSP Staplingとは、TLSの拡張でプライバシー保護と証明書失効検証の誤りへの対策です。まずは全*go.jpドメインで見てみましょう。
gojpb-09
独法を除いた場合、以下のようになります。
gojpb-10
OCSP Staplingの導入はなかなか進んでいない現状がよくわかります。ただ、先進的な設定をしている政府系サイトもあることがわかります。

SSLサーバー証明書

全*.go.jpドメインのアクティブなサイトのサーバー証明書の発行元の証明書発行サービスで分類したのが以下です。
gojpb-11
独法を除いた場合、以下のようになります。
gojpb-12
やはり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などの長いものはありませんでした。
gojpc-01
また、723のRSA鍵について公開指数は全て65537(0x10001)でした。公開指数に3などが使われているために秘密鍵が入手できるといった問題があるサイトは0でした。
gojpc-02

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

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

Google Chromeが2017年1月までにSHA1証明書に対して段階的に警告を出していき、SHA2証明書への移行を促すというマイルストーンがアナウンスされていますが、有効期限がどの時期であるかを調べてみました。
gojpc-05
有効期限が2017年1月を超える証明書が144サイトであり、Chromeでの警告表示を避けるためにSHA2証明書へのリプレースが必要になります。

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

おわりに

以上、*.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通信はできて証明書は取れるんだけど、対応暗号スイートを調べようとするとタイムアウトしちゃうサイトが一つあったため、こんなことになってます。