自堕落な技術者の日記 - livedoor Blog（ブログ）

2015年05月14日21:40

カテゴリ: SSLTLS; ウェブサーバー

CRYPTREC/IPA「SSL/TLS暗号設定ガイドライン」の公開と非公式設定ファイル生成ツールの公開

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) ツールのリンク切れを修正しました。

タグ：: #SSLTLS; #ウェブサーバー; #設定ファイル; #Apache; #nginx; #CRYPTREC; #IPA; #lighttpd; #OpenSSL; #暗号スイート

2015年05月11日00:51

カテゴリ: SSLTLS; 脆弱性

SSL Pulseの統計情報で見るSSL/TLS (2015年5月版)

SSL Pulseサイト(https://www.trustworthyinternet.org/ssl-pulse/)は、 ssllabsでも有名なQualys社が運営しているサイトで、 Webサイト調査のAlexa社による世界のアクセストップ20万サイトを対象にSSL関係の統計情報を毎月公開しています。 3月に引き続き5月のSSL PulseでのSSL/TLSの状況推移をグラフ化してみましょう。隔月で見ていけたらと思っています（＾＾；

脆弱性対応の推移

201505vuln

SSL/TLSプロトコルの推移

201505proto
POODLEの影響でSSLv3の無効化が順調に下がっており、サポートするサイトは40%までに減りました。

SSLサーバー証明書の鍵長、署名アルゴリズムの推移

201505cert
Google ChromeやWindows製品のSHA1証明書のアラート対応を受けて、SHA1とSHA2証明書の比率が逆転しました。今月のグラフで最も特徴的な事かと思います。

新しい技術のサポートの推移

201505adv
OCSP stapling対応率は順調に伸びていますが。大したことはありません。

鍵交換の最低鍵長

201505kx
鍵交換の情報が3月から取れるようになり、ようやく傾向がつかめるようになってきています。

DH鍵交換の最低鍵長

201505dh
DH鍵交換に対応するサイトはわずかながら増えていますが、2048bitだけでなく、安全でないとされる1024bitも増えていること、またそれ以上に安全でない512bitが使われていることは非常に問題です。このような傾向からも、DH鍵交換の鍵長を増やすよう設定するよりも、DH鍵交換は使わず、ECDH系の鍵交換を使うのが良いように思います。

先日ブログに書いたTLSの実装と導入上の推奨をまとめたRFC 7525の4.4節にもDH鍵交換の課題が整理されており、RFC 7525では「使うな」とは言っていませんが、これを読むとDH系の鍵交換は使うべきではないように思います。

ECDH鍵交換の最低鍵長

201505ecdh
ECDH系の鍵交換を使えるサイトと、使えないサイトの比率が逆転し、ECDH系の鍵交換への対応が半数を超えてきました。ECDH系鍵交換を使えない比率の減り方がDHに比べて顕著です。

おわりに

なんか今週末はブログラッシュっすね。メッセージ入りSSLサーバー証明書の件が書けなかったなぁ。今日はこの辺で。

タグ：: #SSL; #TLS; #SSLTLS; #統計情報; #HeartBleed; #BEAST; #RC4; #SSLv3; #X.509証明書; #証明書

2015年05月10日15:23

カテゴリ: S/MIME; Windows

Windows信頼するルート認証機関コンプへの道(第一回)

先日のブログ「Windowsルート証明書の更新プログラム(2014.09)と戯言など」で、

オフラインでルート証明書をアップデートする公式アップデーター http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/rootsupd.exe からルート証明書が「抜ける」んじゃね？と某木村大先生からご指摘いただきました。

実際に試してみたので、ちょっと書いてみたいと思います。

ルート証明書アップデーターからSSTの取り出し

Windows 7以降のオフライン環境で、信頼するルート認証機関のリストをアップデートするのにアップデーター http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/rootsupd.exeがあるというので、早速ダウンロードしてみます。wgetでヘッダ見てみると最終更新は"Wed, 12 Nov 2014 17:33:07 GMT"になっているので、最新のアップデートには対応してそうかな？とも思ったんですが、後に最新のルート更新には対応してなかったことがわかりますorz

これはCAB形式自己解凍アーカイブみたいになっているので、exe2cab(Vectorのは64bitでは動作せず)を使って中身のcabファイルを取り出します。

cabファイルの中はこんな感じ。

ADVPACK.DLL
authroots.sst - ルートのスモールセット？
delroots.sst - 削除するルート
roots.sst - 最小限の2つのルート
rootsupd.inf -
updroots.exe - ルートを更新するプログラム
updroots.sst - 追加される多くのルート

cabファイルのタイムスタンプ見てみたら、2013年4月になっているので、どうも直近の2014年9月の更新に対応したアップデートファイルでは無さそうな雰囲気です。

SSTファイルからのルート証明書の取り出し

*.sstファイルはMicrosoft Serialized Certificate Filesというフォーマットらしく、前にも力技で証明書取り出すスクリプトを書いた記憶があるんですがorz、ちょっと調べてみたらPowerShellのExport-CertificateやImport-Certificateで操作できそうな雰囲気。サンプルにはSSTに証明書を追加する例なんかも紹介されていました。ところが、どうもSSTから証明書を取り出す方法がよくわからずに結局断念。

もうちょっと調べてみるとSSTの中の個々の証明書エントリはSerializedCertificateEntryという構造になっているらしく、SSTのヘッダ情報のあとはこの並びになっているので、Perlでちゃちゃっと抜き出すスクリプトを書きました。

id - 4byte 0x00000020
encodingType - 4byte 0x00000001 (= ASN.1 encoding)
length - 4byte 続く証明書データの長さ
certificate - 可変長 証明書生データ

取り出せた証明書の数はこんな感じ、2014年9月のルートの更新では411だそうですから、かなり少なめ。古い情報っぽくてちょっと萎え気味。

SSTファイル	ルート証明書数
authroots.sst	77
roots.sst	6
updroots.sst	275
計	358

で、ぽちぽちルート証明書を開いてみる

とまぁ、ルート証明書の取り出しはできたので、これをそれぞれ開いてみると「インターネットオプション＞コンテンツ＞証明書＞信頼されたルート認証機関」に未表示のものだったら、表示されるようになります。

Windows 8.1 Proの最新パッチ済の環境で、358のうち、有効期限切れになっているものや、すでにMicrosoftが登録削除しているものもあるようで、最終的には271個のルート認証機関がちゃんと表示されるようになりました。これの作業前は確か27だったので、大躍進という感じではあります。
winroot
(TURKTRUSTが表示されていることに他意はありません（＾＾；

おわりに

いや～～、隠し球っぽくて気持ち悪かったのが、表示されて随分すっきりしますね～～。ただ、

やっと271は表示されたが411まではまだ遠い

私はビックリマンチョコ世代ではないですが、仮面ライダースナックとか集めましたね～～。ソシャゲーのコンプガチャみたいんなもんなんですかね～～。最後までちゃんと表示させたくなりますよね～～～。 411まではまだ道のりは遠い感じですねぇ。やっぱり、Certificate Transparencyのデータに手をつけないといかんかなぁ、、、と思っているところです。

今日は、この辺で、、、

タグ：: #ルート認証局リスト; #トラストアンカ; #Windows; #Windowsルート証明書プログラム; #exe2cab; #SST; #信頼されたルート認証機関

2015年05月09日02:18

カテゴリ: SSLTLS; ISO/IEC規格

「RFC 7525 TLSとDTLSの安全な利用に関する推奨事項」の公開

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

今日はこの辺で

タグ：: #RFC7525; #暗号スイート; #CipherSuite; #SSLTLS; #プロトコル; #BCP; #ベストカレントプラクティス; #PFS; #RC4; #GCM

2015年05月03日10:19

カテゴリ: SSL証明書; Windows

Windowsルート証明書の更新プログラム(2014.09)と戯言など

随分昔の話になりますが、 2014年9月に現時点で最新のWindowsルート証明書プログラムのリストが公開されており、今日は久々にこれを見ていこうと思います。

数年前、Windowsルート証明書の更新プログラムで登録されているルート認証機関にどんな変更があったのか、調査をしてブログで公開していた時期がありました。その時はWindows XPの時代で、登録されているルート認証機関はすべて表示されるようになっていたので、ルート証明書を全部取り出すプログラムを書いて、前回との差分を比較していただけだったので、比較的簡単に調査ができたわけです。

ところが、Windows 7以降、Windowsのルート証明書は、最初からすべて登録されるわけではなくなってしまいました。ちゃんと調べたわけではないので、わからないのですが、確かOSインストール直後は15～25ぐらいの主要なルート認証機関しか登録、ならびに表示されておらず、表示されていないルート認証局のサイトにアクセスした場合に、動的に登録されたルート証明書が追加されるような仕組みに変更になりました。

Windows 7以降のルート認証局リストの仕組みの問題点

Windows 7より導入されたルート認証局リストの配布方式は、個人的に「スッキリしない」というか「嫌だなぁ」と思っています。理由はこんなところです。

ルート認証局のリストはPDFの文書として公開されているが、維持組織、国、認証局名、鍵アルゴリズム、鍵長、ルート証明書ハッシュ値(拇印)しか公開されておらず、識別名や証明書の内容はわからないままである。中には、初期状態で表示されない RSA 1000bitのルート証明書が残っていたりする。
初期状態では20程度の認証局しか表示されておらず、利用者がどの認証局を信頼していることになっているのか、これを知る方法が上のリストのみで十分でない。
例えば、ある小国の認証局を全世界の人が信頼する必要があるとは思えない。不正発行などの事故を起こした場合に、信頼していないほうが良かったという事もあるだろう。そのような時に、自分が信頼している認証局がどこであるのかを把握できないのは問題だ。
Windows 7以降のシステムが認めたルート認証局は削除したとしても、再度アクセスする際に復活してしまう。ユーザは余計な認証局を利用停止や無効化することができない。
つまる所、最初からルート認証局リストが明示されず、後出しジャンケンのようにルート認証局が接続時に追加されるのは如何なものだろうか。

もちろんモバイル向けに初期配布のルート認証局は小さくしたいというのも、わかる気はしますが、どうせ400程度ですから、大したデータ量でもないので、最初から登録してあったほうが潔いと思います。

2014年9月版 Windowsルート証明書の更新

2014年9月のWindowsルート証明書の更新では、411のルート証明書が登録されています。

国別で見てみると、52ヶ国のルート証明書が登録されており、内訳は多い順に以下のようになっています。やっぱり、米国、スペインは多いですね。意外に少ないなぁと思うのが英国、オーストラリアです。
country

次にルート証明書の公開鍵アルゴリズムと鍵長についても見てみましょう。
keylen
RSA 2048bitがやはり多いですが、 RSA 4096bit、楕円曲線暗号のECC NIST P-384曲線もかなり増えています。 Comodo、 DigiCert、 Entrust、 GlobalSign、 Symantec、 Trend Microが楕円のルート証明書を持っています。そういえば、 Microsoftから発行されているリストには SHA1かSHA2かの情報って無いんですよね。残念だなぁ。やっぱり、ルート証明書そのものをダウンロードできるようにしてほしいなぁ。 Appleも、最初はルート証明書の詳しい情報を出していたんですが、最近はMicrosoftに習って、詳しい情報出すの止めちゃったんですよね～～。寂しい話です。

ルート証明書数の推移

Windows系、Android、Mac OS X、iOSでデフォルトのルート証明書の数がどう増えていったのかグラフにしてみました。Apple製品は公式サイトの情報から取得しています。Androidについては拙作のRoot CA Viewer Liteか過去の他作業を元に調べています。
osroot
iOSはiOS3以降、メジャーバージョン毎にルート証明書リストが公開されているのですが、Mac OS Xについては新しいMavericksとYosemiteしか情報がありませんでした。 Apple iOSについては、ルートの数が乱高下していて、なんか掲載ポリシーが定まってない感じなんですかね？本当はMozillaやJavaについても調べてみたかったんですが、これは今後の課題ということで、、、(^^;

Windowsルート証明書のリストを調べる地道な作業 (泣)

以前は、自前のツールを使えば簡単にルート証明書を抽出できたので、今回のような情報を比較的簡単に調査することができたんですが、 Windows 7以降、そうした事もできなくなってしまいました。で、今回はというと、こんな地味な手順を踏んで調査したんです(泣)。Microsoftの中の人ならリストのエクセルファイルとか、ルート証明書そのものを持っていて簡単に調査できるんでしょうけどねぇ、、、トホホ。

公開されているPDFファイル「 Windows Root Certificate Program Members - September 2014」からCERTIFICATES IN DISTRIBUTION FROM ALL MEMBER CAsの表を各ページ、テキストでコピペする。
Emacsのテキスト編集で何とか、TSV(タブ区切り)ファイルにする。
Macのテキストエディタで開きUTF-16で保存する。
MacのExcelでインポートする。
インポートした時点で、カラム位置のズレや文字化けがあるので手作業で修正。
ルート証明書リストのExcelが完成！！！ (泣)
ちゃんとしたエクセル表なので、フィルタ使って調べたり、簡単なスクリプト書いて集計したりできる。

さらなる野望

家族から「リビングにファンが煩いマシンを置くな！」と非難され、泣く泣くファンレスの超小型マシンDiginnos LIVAをサーバー代わりに使っているんですが、ブラウザで変なサイトに行くこともあまりないので、ルート認証局のリストは27で、初期出荷時からあまり増えていないはずで、今回、試しに開いて、イタリアのActalis Authentication CA G1が増えてしまいました。
windialog
なんかこう、あれです、411もあるわけですから、フルコンプしたいですよねぇ？先生、大事なことだからもう一回言います。

フルコンプしたいですよねぇ？！！！

これをフルコンプするには、 411の全ての認証局それぞれに、そこから発行されたどれか一つのSSLサーバー証明書を使っているサイト見つけて、Internet ExplorerでHTTPSアクセスすればいいだけですが、マイナーな認証局から発行された証明書を使っているサイトを見つけるなんて、海水浴行った海岸のどこかで落とした10円玉見つけるようなもんで、ほとんど無理ですよね。例えば、Symantecなんかは色んな認証局を買ったので、グループだけで70もの認証局が登録されているわけですが、Symantecにそれぞれの認証局から発行された証明書のすべてを見つけるなんて、もう無理です。

こういう時ですねぇ、Certificate Transparencyの公開監査ログを手元に持っているとですねぇ、740万枚ぐらいのサーバー証明書と、そのルート認証局までのチェーンがあるので、それぞれのルート証明書を取り出して、Windowsルート証明書情報のPDFに記載された証明書の拇印ハッシュ値とを比較すれば、そこから発行されたSSLサーバー証明書が一つみつかるので、そこへアクセスすれば前述の「証明書ダイアログ」に表示されるのではないかと！！！(パチパチ)

ゴールデンウィーク中に、ちょっとGo言語でこんなツールを作ろうかなぁ、、、と思ってます。

おわりに

いや～、オレのゴールデンウィークは有意義だなぁ、、、 (遠い目 ) こんなことばかりしているとカミさんに怒られるので、今日はこのへんで。

追記(2015.05.03 13:28)

オフラインでルート証明書をアップデートする公式アップデーター http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/rootsupd.exe からルート証明書が「抜ける」んじゃね？と某木村大先生からご指摘いただきました。確かにそのとおりでした。(つ～か、前にツール使ってそれができてたものが、参照情報しか取れなくなったと勘違いしてできなくなって、そのままにしてたんですが、指摘を頂いてから見てみたらちゃんとありました。) その実行ファイルには、証明書のリストである .SST (Microsoft Serialized Certificate Files)が入っており、その中からルート証明書が取り出せそうです。前は作ったツール使ってたんですが、今は PowerShell から取り出せそう。試したらまた報告します。ルート証明書が抜けたとして、ただ開いただけで、「信頼するルート認証機関」のリストに表示されるんかいな？？？