TLS,DTLSを安全に使用するための推奨事項

internet-draft

"この記事はdraft01を元に書かれております。既にdraft05が公開されており、幾つか変更されておりますご注意下さい"



IETFのUsing TLS in Applicationsワーキンググループ(uta wg)にて、アプリケーションプロトコル(SMTP,POP,HTTP...)の実装者や開発者向けの、TLSに関するドキュメント整備が行われいます。


例えば以下の様なドキュメントである。
「Overview and Analysis of Overhead Caused by TLS」TLSを使用することによる各種オーバヘッド(通信量・計算量・ラウンドトリップ回数)に関するドキュメント。
「Summarizing Current Attacks on TLS and DTLS」既存のTLS,DTLSへの攻撃手法をまとめたドキュメント。


今回はその中の一つである
「Recommendations for Secure Use of TLS and DTLS」を斜め読みしたのでまとめる。


なお、本文章中でも注意されている通り、現状広く利用できる暗号方式にフォーカスしておりTLS1.3等が使用できるようになれば、そちらを使うことが推奨されています。


また、必要最低限の推奨事項であり実際に使用する際は個々の仕様に基いてより厳密な必要条件がある場合もあります。


SHOULDやMUSTと言った単語は、RFC 2119の定義を参照下さい。（検索すれば日本語訳も見つかると思います）

プロトコルのバージョン

古いものや安全でないバージョンのSSL,TLSを使用しないことが重要です。

  • SSLv2を使用してはいけない(MUST NOT)。SSLv2は深刻な脆弱性がある
  • SSLv3を使用すべきではない(SHOULD NOT)。SSLv2の脆弱性は修正されているものの、強固な暗号スイートをサポートしていない
  • TLSv1をネゴシエーションすべきでない(SHOULD NOT) 。TLS1.0にはSSLv3へのダウングレード攻撃が存在します。
  • TLSv1.1をネゴシエーションしてもよい。ダウングレード攻撃を防ぐことはできるが、幾つかの強固な暗号スイートをサポートしていません。
  • TLSv1.2をサポートすべき(SHOULD)。そしてTLSv1.2をネゴシエーションしたほうが良い。

SSLへのフォールバック

サーバが高いバージョンのSSL/TLSを拒否した場合に、SSLv3を用いて再び接続を試みるクライアント実装もあります。これは、MITMによって用意に強制されうる。
SSLv3のみのサーバは一般的なWebサーバのうち3%しかありません。それゆえTLSからSSLv3へのフォールバックはすべきでありません(SHOULD NOT)

TLSの常時使用

保護されていない通信と、TLSで保護された通信を組み合わせることで、SSLストリッピングと同様の攻撃が可能になる場合があります。
もし、選択できるのであればTLSの常時使用を選ぶべきです(SHOULD)


また、HSTSと言ったサーバからクライアントに常時使用をアドバタイズ出来る場合はすべきです(SHOULD)

暗号スイート

古いものや安全でない暗号スイートの使用をやめ、現在の安全な暗号スイートを使用することが重要です。

  • ヌル暗号スイートをネゴシエーションしてはいけない(MUST NOT)。ヌル暗号はスイートは実際には暗号化をしない要求ですので、全く安全ではありません。
  • RC4暗号スイートをネゴシエーションしてはいけない(MUST NOT)。RC4は幾つかの暗号的な弱点を持ちます。
  • "輸出レベル"と呼ばれる暗号スイートをネゴシエーションしてはいけない(MUST NOT)。40bit〜56bitのアルゴリズムであり、容易に突破されます。
  • 128bitセキュリティ以下の暗号スイートをネゴシエーションすべきではない(SHOULD NOT)。幾つかのレガシーな暗号スイート(168bit 3DES)は一般的な鍵長よりも少ない有効鍵長になります。これらの暗号スイートは有効化議長によって評価されるべきです。
  • "EDH", "DHE", "ECDHE"といった"forward secrecy"な暗号スイートをサポートしなければならない(MUST)。そして、ネゴシエーションすべきです(SHOULD)


先述の考慮事項のように、以下の暗号スイートが推奨されます

  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384


認証付暗号化方式(AEAD)ですので、残念ながらこれらの暗号スイートはTLS1.2でのみ使用できます。

鍵長

1024bitのDiffie-Hellman鍵は80bitの共通鍵見積もられているため、DH系統の暗号スイートのために長い鍵を使用するほうが好ましい。残念ながら、幾つかのソフトウェア実装では1024bit以上の鍵を扱うことが出来ません。これらのシステムへの、もっとも一般的なワークアラウンドはECDHE系の暗号スイートを使用することです。


加えて、2048bitサーバ証明書は、SHA-256署名が推奨されます。クライアントはTLS1.2で定義される”Signature Algorithms”を使用して、サーバにSHA-256の要求している事を示すべきです(SHOULD)


ノート：先述の推奨事項は予備的なもので、おそらくこの文書の将来のバージョンで修正されます。

圧縮

攻撃を防ぐためにTLSレベルでの圧縮を無効にすべきです(SHOULD)

セッション再開

TLSのセッション再開が使用される場合、安全に行うべきです。
特に、再開情報(セッションIDとセッションチケット)は攻撃者によって修正や盗聴を防ぐために、暗号化し認証する必要があります。
セッションチケットを暗号化する際は、強い暗号スイート(最低でも現在TLSで主に使用されている暗号スイート程)を使用されなければなりません(MUST)。
チケットは定期的に変更しなくていはいけません(MUST)。セッションチケットの正当性は制限されるべきです(例えば1日とか)

リネゴシエーション

ハンドシェイク・リネゴシエーションが実装されている場合、クライアントとサーバの両方はrenegotiation_infoエクステンションを実装すべきです(SHOULD)
れている場合、クライアントとサーバの両方はrenegotiation_infoエクステンションを実装すべきです(SHOULD)