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