3. General Recommendations (一般的な推奨事項)

このセクションでは, TLS の安全な使用に関する一般的な推奨事項を提供します。暗号スイートに関連する推奨事項については, 次のセクションで説明します。

3.1. Protocol Versions (プロトコルバージョン)

3.1.1. SSL/TLS Protocol Versions (SSL/TLS プロトコルバージョン)

古い, より安全性の低いバージョンの SSL/TLS の使用を停止し, より現代的で安全なバージョンの使用を開始することの両方が重要です。したがって, TLS/SSL プロトコルバージョンに関する推奨事項は次のとおりです:

実装は SSL バージョン 2 をネゴシエーションしてはなりません (MUST NOT)。

理論的根拠: 今日, SSLv2 は安全でないと見なされています [RFC6176]。
実装は SSL バージョン 3 をネゴシエーションしてはなりません (MUST NOT)。

理論的根拠: SSLv3 [RFC6101] は SSLv2 よりも改善されており, いくつかの重大なセキュリティホールを修正しましたが, 強力な暗号スイートをサポートしていません。SSLv3 は TLS 拡張をサポートしておらず, その一部 (たとえば, renegotiation_info [RFC5746]) はセキュリティ上重要です。さらに, POODLE 攻撃 [POODLE] の出現により, SSLv3 は現在広く根本的に安全でないと認識されています。詳細については [DEP-SSLv3] を参照してください。
実装は TLS バージョン 1.0 [RFC2246] をネゴシエーションすべきではありません (SHOULD NOT)。唯一の例外は, ネゴシエーションでより高いバージョンが利用できない場合です。

理論的根拠: TLS 1.0 (1999年公開) は多くの現代的で強力な暗号スイートをサポートしていません。さらに, TLS 1.0 は CBC ベースの暗号スイートにレコードごとの初期化ベクトル (IV) がなく, 一般的なパディングエラーに対して警告しません。
実装は TLS バージョン 1.1 [RFC4346] をネゴシエーションすべきではありません (SHOULD NOT)。唯一の例外は, ネゴシエーションでより高いバージョンが利用できない場合です。

理論的根拠: TLS 1.1 (2006年公開) は TLS 1.0 よりもセキュリティが向上していますが, 依然として特定のより強力な暗号スイートをサポートしていません。
実装は TLS 1.2 [RFC5246] をサポートしなければならず (MUST), TLS の以前のバージョンよりも TLS バージョン 1.2 のネゴシエーションを優先しなければなりません (MUST)。

理論的根拠: いくつかのより強力な暗号スイートは TLS 1.2 (2008年公開) でのみ利用可能です。実際, 本文書が推奨する暗号スイート (以下のセクション 4.2) は TLS 1.2 でのみ利用可能です。

この BCP は TLS 1.2 およびそれ以前のバージョンに適用されます。読者がこの BCP の推奨事項が TLS の将来のバージョンに適用されると仮定するのは安全ではありません。

3.1.2. DTLS Protocol Versions (DTLS プロトコルバージョン)

DTLS は UDP データグラム用の TLS の適応であり, TLS 1.1 が公開されたときに導入されました。DTLS に関する推奨事項は次のとおりです:

実装は DTLS バージョン 1.0 [RFC4347] をネゴシエーションすべきではありません (SHOULD NOT)。

DTLS のバージョン 1.0 は TLS のバージョン 1.1 に対応しています (上記参照)。
実装は DTLS バージョン 1.2 [RFC6347] をサポートしなければならず (MUST), ネゴシエーションを優先しなければなりません (MUST)。

DTLS のバージョン 1.2 は TLS のバージョン 1.2 に対応しています (上記参照)。(DTLS のバージョン 1.1 はありません。)

3.1.3. Fallback to Lower Versions (下位バージョンへのフォールバック)

サーバーがプロトコルの上位バージョンを拒否した後にプロトコルの下位バージョンに「フォールバック」するクライアントは, SSLv3 以前にフォールバックしてはなりません (MUST NOT)。

理論的根拠: 一部のクライアント実装は, サーバーがプロトコルの上位バージョンを拒否した場合, TLS の下位バージョンや SSLv3 にまで戻ります。このフォールバックは中間者 (MITM) 攻撃者によって強制される可能性があります。TLS 1.0 と SSLv3 は本文書が推奨するバージョンである TLS 1.2 よりもはるかに安全性が低いです。TLS 1.0 専用サーバーは依然として非常に一般的ですが, IP スキャンによると SSLv3 専用サーバーは現在の Web サーバー人口の約 3% にすぎません。(この執筆時点で, ダウングレード攻撃を防ぐための明示的な方法が最近 [RFC7507] で定義されています。)

3.2. Strict TLS

以下の推奨事項は, SSL Stripping を防ぐのに役立つように提供されています ([RFC7457] のセクション 2.1 で要約されている攻撃):

アプリケーションプロトコルが実装またはデプロイに厳格な TLS 構成と暗号化されていないトラフィックから TLS 保護トラフィックへの動的アップグレード (STARTTLS など) の間の選択を許可する場合, クライアントとサーバーは厳格な TLS 構成を優先すべきです (SHOULD)。
アプリケーションプロトコルは通常, 初期プロトコル交換中にサーバーが TLS を提供する方法を提供し, 場合によってはサーバーが TLS のサポートを宣伝する方法も提供します (たとえば, TLS が必要であることを示すフラグを通じて)。残念ながら, これらの表示は通信チャネルが暗号化される前に送信されます。クライアントは, これらの表示がサーバーによって通信されない場合でも, TLS のネゴシエーションを試みるべきです (SHOULD)。
HTTP クライアントとサーバーの実装は, Web サーバーが TLS 専用クライアントを受け入れる意思があることを宣伝できるようにするため, HTTP Strict Transport Security (HSTS) ヘッダー [RFC6797] をサポートしなければなりません (MUST)。
Web サーバーは, TLS 専用クライアントを受け入れる意思があることを示すために HSTS を使用すべきです (SHOULD)。ただし, HSTS を使用することが実際に全体的なセキュリティを弱める方法でデプロイされている場合を除きます (たとえば, 自己署名証明書で HSTS を使用することは問題になる可能性があります。[RFC6797] のセクション 11.3 を参照)。

理論的根拠: 保護されていない通信と TLS 保護された通信を組み合わせると, SSL Stripping や同様の攻撃への道が開かれます。なぜなら, 通信の初期部分が整合性保護されていないため, 通信をクリアに保つことを目標とする攻撃者によって操作される可能性があるからです。

3.3. Compression (圧縮)

圧縮関連の攻撃を防ぐため ([RFC7457] のセクション 2.6 で要約), 実装とデプロイは TLS レベルの圧縮 ([RFC5246] のセクション 6.2.2) を無効にすべきです (SHOULD)。ただし, 問題のアプリケーションプロトコルがそのような攻撃に対して開かれていないことが示されている場合を除きます。

理論的根拠: TLS 圧縮は, CRIME 攻撃などのセキュリティ攻撃の対象となっています。

実装者は, より高いプロトコルレベルでの圧縮により, アクティブな攻撃者が接続からクリアテキスト情報を抽出できることに注意する必要があります。BREACH 攻撃はそのようなケースの 1 つです。これらの問題は TLS の外部でのみ軽減できるため, 本文書の範囲外です。詳細については [RFC7457] のセクション 2.6 を参照してください。

3.4. TLS Session Resumption (TLS セッション再開)

TLS セッション再開が使用される場合, 安全に行うよう注意を払う必要があります。特に, セッションチケット [RFC5077] を使用する場合, 再開情報は攻撃者による変更や盗聴を防ぐために認証および暗号化されなければなりません (MUST)。セッションチケットにはさらに推奨事項が適用されます:

チケットを暗号化する際には強力な暗号スイートを使用しなければなりません (MUST) (メイン TLS 暗号スイートと少なくとも同程度に強力)。
チケット鍵は定期的に (たとえば, 毎週) 変更しなければなりません (MUST)。これにより, 前方秘匿性の利点が無効にならないようにします (前方秘匿性の詳細についてはセクション 6.3 を参照)。
同様の理由から, セッションチケットの有効性は妥当な期間に制限されるべきです (SHOULD) (たとえば, チケット鍵の有効性の半分の長さ)。

理論的根拠: セッション再開は別の種類の TLS ハンドシェイクであり, したがって初期ハンドシェイクと同じくらい安全でなければなりません。本文書 (セクション 4) は前方秘匿性を提供する暗号スイートの使用を推奨しています。つまり, TLS エンドポイント (クライアントまたはサーバー) とその秘密に瞬間的にアクセスした攻撃者が過去または将来の通信を読むことを防ぎます。チケットはこのセキュリティプロパティを無効にしないように管理されなければなりません。

3.5. TLS Renegotiation (TLS 再ネゴシエーション)

ハンドシェイク再ネゴシエーションが実装されている場合, クライアントとサーバーの両方が [RFC5746] で定義されている renegotiation_info 拡張を実装しなければなりません (MUST)。

Triple Handshake 攻撃に対抗する最も安全なオプションは, 再ネゴシエーション中の証明書の変更を拒否することです。さらに, TLS クライアントは接続を介して受信されたすべての証明書に同じ検証ポリシーを適用すべきです (SHOULD)。[triple-handshake] 文書は, マスターシークレットを完全なハンドシェイクにバインドする ([SESSION-HASH] を参照) や省略されたセッション再開ハンドシェイクを元の完全なハンドシェイクにバインドするなど, 他のいくつかの可能な対策を提案しています。後者の 2 つの技術はまだ開発中であり, したがって現在のプラクティスとしての資格がありませんが, TLS を実装およびデプロイする人々は適切な対策のさらなる開発を注視することが推奨されます。

3.6. Server Name Indication (サーバー名表示)

TLS 実装は, HTTPS を含む恩恵を受ける上位レベルプロトコルに対して, [RFC6066] のセクション 3 で定義されている Server Name Indication (SNI) 拡張をサポートしなければなりません (MUST)。ただし, 特定の状況での SNI の実際の使用はローカルポリシーの問題です。

理論的根拠: SNI は単一のアドレス上に複数の TLS 保護された仮想サーバーのデプロイをサポートし, したがってこれらの仮想サーバーにきめ細かいセキュリティを可能にします。各サーバーが独自の証明書を持つことを許可することによって実現されます。