メインコンテンツまでスキップ

3. 一般的な推奨事項

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

3.1. プロトコルバージョン​

3.1.1. SSL/TLS プロトコルバージョン​

安全性に劣る古いバージョンの SSL/TLS の使用を停止し、より安全で最新のバージョンを使い始めることは重要です。したがって、TLS/SSL プロトコルバージョンに関する推奨事項は以下のとおりです。

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

    理由: 今日、SSLv2 は安全ではないと見なされています [RFC6176]。

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

    理由: SSLv3 [RFC6101] は SSLv2 よりも改善されており、いくつかの重大なセキュリティホールを塞ぎましたが、強力な暗号スイートをサポートしていません。SSLv3 は TLS 拡張をサポートしておらず、その一部（例: renegotiation_info [RFC5746]）はセキュリティ上重要です。さらに、Padding Oracle On Downgraded Legacy Encryption (POODLE) 攻撃 [POODLE] の出現により、SSLv3 は根本的に安全ではないと広く認識されています。詳細については [RFC7568] を参照してください。

  • 実装は TLS バージョン 1.0 [RFC2246] をネゴシエートしてはなりません (MUST NOT)。

    理由: TLS 1.0 (1999 年公開) は、多くの最新の強力な暗号スイートをサポートしていません。さらに、TLS 1.0 には、暗号ブロック連鎖 (CBC) に基づく暗号スイートごとのレコード初期化ベクトル (IV) がなく、一般的なパディングエラーに対して警告しません。これとこのセクションの他の推奨事項は [RFC8996] に沿っています。

  • 実装は TLS バージョン 1.1 [RFC4346] をネゴシエートしてはなりません (MUST NOT)。

    理由: TLS 1.1 (2006 年公開) は TLS 1.0 よりもセキュリティが向上していますが、2008 年の TLS 1.2 の標準化で導入された特定のより強力な暗号スイートをまだサポートしていません。これには、本書で TLS 1.2 に推奨される暗号スイートが含まれます (以下のセクション 4.2 を参照)。

  • 実装は TLS 1.2 [RFC5246] をサポートしなければなりません (MUST)。

    理由: TLS 1.2 は現時点で TLS 1.3 よりも広く実装および展開されており、既知の攻撃を緩和するために本書の推奨事項に従う場合、TLS 1.2 の使用は TLS 1.3 の使用と同じくらい安全です。TLS と DTLS を再利用するほとんどのアプリケーションプロトコルでは、TLS 1.3 のみに移行する緊急の必要性はありません。実際、多くのアプリケーションクライアントはまだ TLS 1.3 をサポートしていない TLS ライブラリまたはオペレーティングシステムに依存しているため、TLS 1.2 を積極的に廃止すると重大な相互運用性の問題が発生し、セキュリティを助けるどころか害を及ぼす可能性があります。それにもかかわらず、この BCP の将来のバージョンでは、適切な時期に TLS 1.2 の使用を廃止することが予想されます。

  • 実装は TLS 1.3 [RFC8446] をサポートすべきであり (SHOULD)、実装されている場合は、以前のバージョンの TLS よりも TLS 1.3 のネゴシエーションを優先しなければなりません (MUST)。

    理由: TLS 1.3 はプロトコルの大幅な見直しであり、TLS 1.2 のセキュリティ問題の多くを解決します。実装が TLS 1.2 をサポートする範囲内で (TLS 1.3 がデフォルトであっても)、本書で指定されている TLS 1.2 に関する推奨事項に従わなければなりません (MUST)。

  • TLS/DTLS ハンドシェイクプロトコルおよび/またはレコードレイヤーを統合する新しいトランスポートプロトコルは、TLS/DTLS 1.3 のみを使用しなければなりません (MUST) (たとえば、QUIC [RFC9001] はこのアプローチを採用しました)。チャネルまたはセッションの暗号化に TLS/DTLS を採用する新しいアプリケーションプロトコルは、TLS/DTLS バージョン 1.2 と 1.3 の両方と統合しなければなりません (MUST)。それにもかかわらず、広範な相互運用性が懸念されないまれなケースでは、アプリケーションプロトコル設計者は TLS 1.2 を放棄することを選択してもかまいません (MAY)。

    理由: TLS 1.3 の安全な展開は、TLS 1.2 の安全な展開よりも大幅に簡単で、エラーが発生しにくいです。QUIC などの新しい安全なトランスポートプロトコルを設計する場合、TLS 1.2 をサポートする理由はありません。対照的に、TLS を再利用する新しいアプリケーションプロトコルは、両方のバージョンの基盤となるライブラリまたはオペレーティングシステムのサポートを活用するために、TLS 1.3 と TLS 1.2 の両方をサポートする必要があります。

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

3.1.2. DTLS プロトコルバージョン​

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

  • 実装は DTLS バージョン 1.0 [RFC4347] をネゴシエートしてはなりません (MUST NOT)。

    DTLS のバージョン 1.0 は、TLS のバージョン 1.1 に対応しています (上記参照)。

  • 実装は DTLS 1.2 [RFC6347] をサポートしなければなりません (MUST)。

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

  • 実装は DTLS 1.3 [RFC9147] をサポートすべきであり (SHOULD)、実装されている場合は、以前のバージョンの DTLS よりも DTLS バージョン 1.3 のネゴシエーションを優先しなければなりません (MUST)。

    DTLS のバージョン 1.3 は、TLS のバージョン 1.3 に対応しています (上記参照)。

3.1.3. 低バージョンへのフォールバック​

TLS/DTLS 1.2 クライアントは、以前の TLS バージョンが廃止されているため [RFC8996]、それらのバージョンにフォールバックしてはなりません (MUST NOT)。その結果、クライアントにはダウングレード保護 Signaling Cipher Suite Value (SCSV) メカニズム [RFC7507] が不要になりました。さらに、TLS 1.3 は新しいバージョンネゴシエーションメカニズムを実装しています。

3.2. Strict TLS​

「SSL ストリッピング」および STARTTLS コマンドインジェクション ([RFC7457] にまとめられている攻撃) を防ぐために、以下の推奨事項が提供されています。

  • 多くの既存のアプリケーションプロトコルは、TLS の使用が一般的になる前に設計されました。これらのプロトコルは通常、TLS 専用通信用の別のポート (例: HTTPS 用のポート 443) を介するか、チャネルを暗号化されていない状態から TLS 保護状態に動的にアップグレードする方法 (例: IMAP や XMPP などのプロトコルで使用される STARTTLS) を介して、2 つの方法のいずれかで TLS をサポートします。通信チャネルを保護するメカニズム (TLS 専用ポートまたは動的アップグレード) に関係なく、重要なのはチャネルの最終状態です。プロトコルが動的アップグレード方法と個別の TLS 専用方法の両方を定義する場合、実装は個別の TLS 専用方法をサポートしなければならず (MUST)、管理者は動的アップグレード方法よりも優先して使用するように構成しなければなりません (MUST)。プロトコルが動的アップグレード方法のみをサポートする場合、実装は管理者がネゴシエートされた TLS チャネルがない場合にプレーンテキストの使用を禁止する厳密なローカルポリシーを設定する方法を提供しなければならず (MUST)、管理者はこのポリシーを使用しなければなりません (MUST)。

  • World Wide Web (セクション 5 を参照) での使用を目的とした HTTP クライアントおよびサーバー実装は、Web サーバーが TLS 専用クライアントを受け入れる意思があることをアドバタイズできるように、HTTP Strict Transport Security (HSTS) ヘッダーフィールド [RFC6797] をサポートしなければなりません (MUST)。Web サーバーは、HSTS を使用すると実際に全体的なセキュリティが弱まるような方法で展開されていない限り (たとえば、[RFC6797] のセクション 11.3 で説明されているように、自己署名証明書で HSTS を使用すると問題になる可能性があります)、TLS 専用クライアントを受け入れる意思があることを示すために HSTS を使用すべきです (SHOULD)。HTTP 以外のアプリケーションプロトコルにも同様の技術が存在します。たとえば、メール転送エージェント用の Mail Transfer Agent Strict Transport Security (MTA-STS) [RFC8461] や、SMTP [RFC7672] および XMPP [RFC7712] 用の DNS-Based Authentication of Named Entities (DANE) [RFC6698] に基づく方法などです。

理由: 保護されていない通信と TLS で保護された通信を組み合わせると、通信の最初の部分が整合性保護されておらず、通信を平文のままにすることを目的とする攻撃者によって操作される可能性があるため、SSL ストリッピングや同様の攻撃への道が開かれます。

3.3. 圧縮​

TLS 1.2 を使用する際の圧縮関連の攻撃 ([RFC7457] のセクション 2.6 にまとめられています) を防ぐために、実装および展開は TLS レベルの圧縮 ([RFC5246] のセクション 6.2.2) をサポートすべきではありません (SHOULD NOT)。唯一の例外は、問題のアプリケーションプロトコルがそのような攻撃に対して開かれていないことが証明されている場合です。ただし、この場合でも、TLS 圧縮に関連する将来の攻撃の可能性があるため、細心の注意が必要です。具体的には、HTTP プロトコルは圧縮関連の攻撃に対して脆弱であることが知られています。(圧縮は TLS 1.3 から削除されたため、この推奨事項は TLS 1.2 のみに適用されます。)

理由: TLS 圧縮は、Compression Ratio Info-leak Made Easy (CRIME) 攻撃などのセキュリティ攻撃の対象となっています。

実装者は、より高いプロトコルレベルでの圧縮により、アクティブな攻撃者が接続から平文情報を抽出できる可能性があることに注意する必要があります。Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext (BREACH) 攻撃はそのようなケースの 1 つです。これらの問題は TLS の外部でのみ緩和できるため、本書の範囲外です。詳細については [RFC7457] のセクション 2.6 を参照してください。

3.3.1. 証明書の圧縮​

証明書チェーンは、多くの場合、ハンドシェイク中に送信されるバイトの大部分を占めます。サイズを管理するために、以下の方法の一部またはすべてを採用できます (詳細な提案については [RFC9191] のセクション 4 も参照)。

  • 名前または拡張の数を制限する。

  • Elliptic Curve Digital Signature Algorithm (ECDSA) のように、公開鍵表現が小さい鍵を使用する。

  • 証明書の圧縮を使用する。

後者を実現するために、TLS 1.3 は [RFC8879] で compress_certificate 拡張を定義しています。その使用に関連するセキュリティとプライバシーの考慮事項については、[RFC8879] のセクション 5 も参照してください。念のため、TLS 圧縮に対する CRIME スタイルの攻撃は、証明書の圧縮には適用されません。

ミドルボックスの干渉の可能性が高いため、[RFC8879] スタイルの圧縮は TLS 1.2 では利用可能になっていません。理論的には、[RFC7924] で定義されている cached_info 拡張を使用できますが、実用的な代替手段と見なされるほど広くサポートされていません。

3.4. TLS セッション再開​

セッション再開は、完全な TLS ハンドシェイクの数を大幅に減らすため、ほとんどの展開にとって不可欠なパフォーマンス機能です。

セッションチケットを使用したステートレスセッション再開は一般的な戦略です。TLS 1.2 の場合、[RFC5077] で指定されています。TLS 1.3 の場合、事前共有鍵 (PSK) の使用に基づくより安全なメカニズムが [RFC8446] のセクション 4.6.1 で説明されています。セッション再開を含む TLS 暗号化の「ショートカット」によって引き起こされるリスクの定量的調査については、[Springall16] を参照してください。

使用する場合、攻撃者による変更や盗聴を防ぐために、再開情報は認証および暗号化されなければなりません (MUST)。セッションチケットにはさらに推奨事項が適用されます。

  • チケットを暗号化するときは、強力な暗号を使用しなければなりません (MUST) (少なくともメインの TLS 暗号スイートと同じくらい強力)。

  • 前方秘匿性の利点を損なわないように (前方秘匿性の詳細についてはセクション 7.3 を参照)、チケット暗号化鍵は定期的に (たとえば週に 1 回) 変更しなければなりません (MUST)。古いチケット暗号化鍵は、有効期間の終了時に破棄しなければなりません (MUST)。

  • 同様の理由で、セッションチケットの有効性は適切な期間 (たとえば、チケット暗号化鍵の有効期間の半分) に制限されなければなりません (MUST)。

  • TLS 1.2 は、単一のセッション内でセッション鍵をロールフォワードしません。したがって、サーバーのチケット暗号化鍵が盗まれ、セッションのコンテンツ全体を復号化するために使用される攻撃 (前方秘匿性の概念を無効にする) を防ぐために、TLS 1.2 サーバーは古すぎるセッション (たとえば、2 つのチケット暗号化鍵ローテーション期間よりも長く開いているセッション) を再開すべきではありません (SHOULD NOT)。

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

TLS 1.3 は、定期的に再開される長寿命の接続内でも前方秘匿性という強力なオプションを提供します。[RFC8446] のセクション 2.2 では、クライアントがセッション再開を開始するときに "key_share" を送信すべきである (SHOULD) と推奨しています。前方秘匿性を得るために、本書では、サーバー実装が "psk_dhe_ke" PSK 鍵交換モードを選択し、"key_share" で応答して、各セッション再開時に Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) 交換を完了すべきである (SHOULD) と推奨しています。よりパフォーマンスの高い代替手段として、サーバー実装は、前回の ECDHE 交換から一定時間 (たとえば、時間単位で測定) が経過するまで "key_share" で応答するのを控えてもかまいません (MAY)。これは、"key_share" 操作が (数時間以内に発生する) 推定される大多数のセッション再開リクエストに対して発生しないことを意味しながら、長寿命セッションの前方秘匿性を確保します。

TLS セッション再開は、サーバーがクライアントを追跡できるという潜在的なプライバシーの問題を引き起こします (場合によっては無期限に)。詳細については [Sy2018] を参照してください。

3.5. TLS 1.2 での再ネゴシエーション​

再ネゴシエーションは TLS 1.3 から削除されたため、このセクションの推奨事項は TLS 1.2 のみに適用されます。

TLS 1.2 での再ネゴシエーションは、既存のセッションの新しい暗号化パラメータを確立するハンドシェイクです。このメカニズムは TLS 1.2 および以前のプロトコルバージョンに存在し、平文インジェクション攻撃 CVE-2009-3555 [CVE] を含むいくつかの主要な攻撃を受けて改善されました。

TLS 1.2 クライアントとサーバーは、[RFC5746] で定義されている renegotiation_info 拡張を実装しなければなりません (MUST)。

TLS 1.2 クライアントは、Client Hello で renegotiation_info を送信しなければなりません (MUST)。サーバーが拡張を認識しない場合、クライアントは接続を終了する前に致命的な handshake_failure アラートを生成しなければなりません (MUST)。

理由: いずれかのエンドポイントが実際に再ネゴシエーションを実装しているかどうかに関係なく、renegotiation_info をサポートしていない TLS 1.2 サーバーにクライアントが接続することは安全ではありません。[RFC5746] のセクション 4.1 も参照してください。

TLS セッションパラメータが適切に認証されていないことに起因する関連攻撃に、トリプルハンドシェイク [Triple-Handshake] があります。この攻撃に対処するために、TLS 1.2 実装は [RFC7627] で定義されている extended_master_secret 拡張をサポートしなければなりません (MUST)。

3.6. ハンドシェイク後の認証​

TLS 1.2 での再ネゴシエーションは、TLS 1.3 で個別のハンドシェイク後認証および鍵更新メカニズムによって (部分的に) 置き換えられました。単一の接続でリクエストを多重化するプロトコル (HTTP/2 [RFC9113] など) のコンテキストでは、ハンドシェイク後認証には TLS 1.2 再ネゴシエーションと同じ問題があります。多重化プロトコルは、[RFC9113] のセクション 9.2.3 で HTTP/2 に提供されているアドバイスに従うべきです (SHOULD)。

3.7. Server Name Indication (SNI)​

TLS 実装は、HTTPS を含む、それから恩恵を受けるより高レベルのプロトコルのために、[RFC6066] のセクション 3 で定義されている Server Name Indication (SNI) 拡張をサポートしなければなりません (MUST)。ただし、特定の状況での SNI の実際の使用はローカルポリシーの問題です。執筆時点では、SNI を暗号化する技術 (Encrypted Client Hello と呼ばれる) が TLS ワーキンググループ [TLS-ECH] で作業中です。その方法が標準化され、広く実装されたら、この BCP の将来のバージョンでその使用を推奨することが適切になるでしょう。

理由: SNI は、単一のアドレスへの複数の TLS 保護された仮想サーバーの展開をサポートし、それぞれが独自の証明書を持つことを可能にすることで、これらの仮想サーバーのきめ細かいセキュリティを可能にします。ただし、SNI は特定の接続のターゲットドメインもリークします。この情報リークは、TLS Encrypted Client Hello 方法が標準化されれば、その使用によって閉じられます。

[ALPACA] で説明されている攻撃を防ぐために、提示されたサーバー名を認識しないサーバーはハンドシェイクを継続すべきではなく (SHOULD NOT)、代わりに致命的なレベルの unrecognized_name(112) アラートで失敗すべきです (SHOULD)。この推奨事項は [RFC6066] のセクション 3 を更新するものであり、以下のように記載されていました。

| サーバーが ClientHello 拡張を理解したがサーバー名を認識しない場合、サーバーは次の 2 つのアクションのいずれかを実行すべきです (SHOULD)。致命的なレベルの unrecognized_name(112) アラートを送信してハンドシェイクを中止するか、ハンドシェイクを継続します。

サーバーが SNI 拡張を認識したが、クライアントが送信したものとは異なるホスト名の証明書を提示した場合、クライアントはハンドシェイクを中止すべきです (SHOULD)。

3.8. Application-Layer Protocol Negotiation (ALPN)​

TLS 実装 (クライアント側とサーバー側の両方) は、Application-Layer Protocol Negotiation (ALPN) 拡張 [RFC7301] をサポートしなければなりません (MUST)。

あるプロトコルで使用することを意図したメッセージが別のプロトコルで使用するためのメッセージと間違われないようにすることに失敗した結果生じる「クロスプロトコル」攻撃を防ぐために、サーバーは [RFC7301] のセクション 3.2 で規定されている動作を厳密に強制することをお勧めします。

| サーバーがクライアントがアドバタイズするプロトコルをサポートしていない場合、サーバーは致命的な 'no_application_protocol' アラートで応答しなければなりません (SHALL)。

サーバーが ALPN 拡張を認識したがクライアントリストからプロトコルを選択しない場合、クライアントはハンドシェイクを中止すべきです (SHOULD)。そうしないと、[ALPACA] で説明されているような攻撃が発生する可能性があります。

プロトコル開発者は、プロトコルの ALPN 識別子を登録することを強くお勧めします。これは新しいプロトコルと確立されたプロトコルの両方に適用されます。ただし、後者は大規模な展開ベースを持っている可能性があるため、確立されたプロトコル用に ALPN 識別子が登録されている場合、ALPN 使用の厳格な強制は実行可能ではない可能性があります。

3.9. マルチサーバー展開​

複数のサーバーまたはサービスを含む展開では、TLS の攻撃対象領域のサイズが増加する可能性があります。2 つのシナリオが興味深いものです。

  1. 複数のサービスが異なるプロトコル (例: HTTP と IMAP) を介して同じドメイン名を処理する展開。この場合、攻撃者は接続エンドポイントを別のプロトコルを提供するサービスに向け、クロスプロトコル攻撃を仕掛けることができる可能性があります。クロスプロトコル攻撃では、クライアントとサーバーは異なるプロトコルを使用していると考えますが、一方のプロトコルで送信されたメッセージが他方のプロトコルのメッセージとして解釈され、望ましくない影響が生じる場合、攻撃者はそれを悪用する可能性があります (このクラスの攻撃の詳細については [ALPACA] を参照)。この脅威を緩和するために、サービスプロバイダーは ALPN を展開すべきです (SHOULD) (セクション 3.8 を参照)。さらに、可能な限り、同じドメイン名を処理する複数のサービスが、本書の推奨事項と一致する同等のレベルのセキュリティを提供することを保証すべきです (SHOULD)。このような対策には、複数の TLS サーバー間の構成の処理と、それらのサーバーが保持する資格情報の侵害に対する保護を含めるべきです (SHOULD)。

  2. 同じサービスを提供する複数のサーバーが異なる TLS 構成を持つ展開。この場合、攻撃者は接続エンドポイントをより悪用しやすい TLS 構成を持つサーバーに向けることができる可能性があります (このクラスの攻撃の詳細については [DROWN] を参照)。この脅威を緩和するために、サービスプロバイダーは、同じサービスを提供するすべてのサーバーが、本書の推奨事項と一致する同等のレベルのセキュリティを提供することを保証すべきです (SHOULD)。

3.10. TLS 1.3 でのゼロラウンドトリップタイム (0-RTT) データ​

0-RTT 早期データ機能は TLS 1.3 の新機能です。TLS 接続が再開されたときの遅延を短縮しますが、特定のセキュリティプロパティが犠牲になる可能性があります。その結果、サーバー側とクライアント側の両方の実装者からの特別な注意が必要です。通常、これは TLS ライブラリとその上のプロトコルレイヤーに及びます。

HTTP over TLS については、[RFC8470] のガイダンスを参照してください。

QUIC on TLS については、[RFC9001] のセクション 9.2 を参照してください。

その他のプロトコルについては、[RFC8446] のセクション 8 および付録 E.5 に一般的なガイダンスがあります。付録 E.5 を言い換えると、アプリケーションは、問題のアプリケーションプロトコルに、いつ 0-RTT が適切で安全かを明確にする明示的な仕様が存在しない限り、この機能を回避しなければなりません (MUST)。これは、IETF RFC、非 IETF 標準、または非標準プロトコルに関連するドキュメントの形式をとることができます。

に最終更新