6. Security Considerations (セキュリティに関する考察)

本文書全体が TLS プロトコルを使用するアプリケーションに直接影響するセキュリティプラクティスについて議論しています。このセクションには, TLS と組み合わせて使用される, または TLS によって使用される技術に関連するより広範なセキュリティの考慮事項が含まれています。

6.1. Host Name Validation (ホスト名検証)

アプリケーション作成者は, 一部の TLS 実装がホスト名を検証しないことに注意すべきです。使用している TLS 実装がホスト名を検証しない場合, 作成者は独自の検証コードを書く必要があるか, 別の TLS 実装の使用を検討する必要があります。

ホスト名検証に関する要件 (および一般的に, TLS 層とその上で実行されるプロトコル間のバインディング) は異なるプロトコル間で異なることに注意してください。HTTPS の場合, これらの要件は [RFC2818] のセクション 3 で定義されています。

TLS コンテキストでの一般的なホスト名検証に関する詳細については, 読者は [RFC6125] を参照してください。さらに, その RFC には例のプロトコルの長いリストが含まれており, そのいくつかは HTTPS とは大きく異なるポリシーを実装しています。

ホスト名が間接的かつ安全でない方法で発見された場合 (たとえば, MX または SRV レコードに対する安全でない DNS クエリによって), 提示された証明書と一致する場合でも参照識別子 [RFC6125] として使用すべきではありません (SHOULD NOT)。この但し書きは, ホスト名が安全に発見された場合には適用されません (詳細な議論については [DANE-SRV] および [DANE-SMTP] を参照)。

ホスト名検証は通常, リーフ「エンドエンティティ」証明書にのみ適用されます。当然, PKI のコンテキストで適切な認証を保証するために, アプリケーションクライアントは [RFC5280] に従って証明書パス全体を検証する必要があります ([RFC6125] も参照)。

6.2. AES-GCM

上記のセクション 4.2 は AES-GCM 認証暗号化アルゴリズムの使用を推奨しています。TLS 1.2 を使用する際の一般的なセキュリティの考慮事項については [RFC5246] のセクション 11 を, TLS で使用される場合に AES-GCM に特に適用されるセキュリティの考慮事項については [RFC5288] のセクション 6 を参照してください。

6.3. Forward Secrecy (前方秘匿性)

前方秘匿性 (「完全前方秘匿性」または「PFS」とも呼ばれ, [RFC4949] で定義) は, セッション鍵が通信当事者の長期鍵でのみ暗号化されている暗号化された会話を記録する攻撃者に対する防御です。攻撃者が後の時点でこれらの長期鍵を入手できた場合, セッション鍵, したがって会話全体が復号化される可能性があります。TLS と DTLS のコンテキストでは, そのような長期鍵の侵害は完全にあり得ないことではありません。たとえば, 次の理由で発生する可能性があります:

他の攻撃ベクトルによってクライアントまたはサーバーが攻撃され, 秘密鍵が取得される。
販売されたデバイスまたは事前のワイプなしで廃止されたデバイスから長期鍵が取得される。
CA などの信頼できる第三者によって生成された鍵で, 後に恐喝または侵害によってそこから取得される [Soghoian2011]。
暗号学的なブレークスルー, または不十分な長さの非対称鍵の使用 [Kleinjung2010]。
システム管理者に対するソーシャルエンジニアリング攻撃。
不十分に保護されたバックアップからの秘密鍵の収集。

前方秘匿性は, そのような場合でも, 攻撃者が会話のしばらく後に長期鍵を入手したとしても, セッション鍵を決定することが実行不可能であることを保証します。また, 長期鍵を所有しているが会話中は受動的である攻撃者からも保護します。

前方秘匿性は一般的に, セッション鍵を導出するために Diffie-Hellman スキームを使用することによって達成されます。Diffie-Hellman スキームでは, 両当事者が秘密を保持し, 特定の巡回群上のモジュラーべき乗としてパラメータをネットワーク上で送信します。いわゆる離散対数問題 (DLP) のプロパティにより, 盗聴者がそれを行うことができない状態で当事者がセッション鍵を導出することができます。十分に大きなパラメータが選択されている場合, 現在 DLP に対する既知の攻撃はありません。Diffie-Hellman スキームの変形は, 元々提案されたモジュラー演算の代わりに楕円曲線を使用します。

残念ながら, 前方秘匿性を特徴としない多くの TLS/DTLS 暗号スイートが定義されました。たとえば, TLS_RSA_WITH_AES_256_CBC_SHA256 です。したがって, 本文書は前方秘匿性のみの暗号の厳格な使用を提唱します。

6.4. Diffie-Hellman Exponent Reuse (Diffie-Hellman 指数の再利用)

パフォーマンス上の理由から, 多くの TLS 実装は複数の接続にわたって Diffie-Hellman および Elliptic Curve Diffie-Hellman 指数を再利用します。そのような再利用は重大なセキュリティ問題を引き起こす可能性があります:

指数が長すぎる期間 (たとえば, 数時間以上) 再利用される場合, ホストへのアクセスを得た攻撃者が以前の接続を復号化できます。言い換えると, 指数の再利用は前方秘匿性の効果を無効にします。
指数を再利用する TLS 実装は, いくつかの既知の攻撃を回避するために, 受信する DH 公開鍵をグループメンバーシップについてテストすべきです。これらのテストは執筆時点で TLS では標準化されていません。DH 指数を再利用する IKEv2 実装に要求される受信者テストについては [RFC6989] を参照してください。

6.5. Certificate Revocation (証明書失効)

以下の考慮事項と推奨事項は, 一般的な公開鍵証明書の失効ステータスをチェックする問題に対する完全で効率的な解決策が存在しないにもかかわらず, 証明書失効に関する最新技術を表しています [RFC5280]:

Certificate Revocation Lists (CRLs) は失効情報を配布するための最も広くサポートされているメカニズムですが, その有用性を制限する既知のスケーリングの課題があります (分割された CRL やデルタ CRL などの回避策があるにもかかわらず)。
Web ブラウザの構成データベースに失効リストを埋め込む独自のメカニズムは, 最も頻繁に使用される少数の Web サーバーを超えてスケールできません。
On-Line Certification Status Protocol (OCSP) [RFC6960] はスケーリングとプライバシーの両方の問題を提示します。さらに, クライアントは通常「ソフトフェイル」します。つまり, OCSP サーバーが応答しない場合に TLS 接続を中止しません。(ただし, これは OCSP レスポンダがオフラインにされた場合のサービス拒否攻撃を回避するための回避策かもしれません。)
TLS Certificate Status Request 拡張 ([RFC6066] のセクション 8), 一般に「OCSP stapling」と呼ばれるものは, OCSP の運用上の問題を解決します。ただし, 攻撃者がクライアントの stapled OCSP レスポンスの要求を単に無視できるため, MITM 攻撃者の存在下では依然として効果がありません。
[RFC6066] で定義されている OCSP stapling は, 証明書チェーンで使用される中間証明書には拡張されません。Multiple Certificate Status 拡張 [RFC6961] はこの欠点に対処していますが, あまりデプロイされていない最近の追加です。
CRL と OCSP の両方は, 特定の種類のノード (最初に起動するためにセキュアな接続を確立する必要がある新しくプロビジョニングされたデバイスなど) では利用できない可能性があるインターネットへの比較的信頼できる接続に依存しています。

一般的な公開鍵証明書に関して, サーバーは最新技術と可能な将来の解決策の基礎を考慮したベストプラクティスとして以下をサポートすべきです (SHOULD):

OCSP [RFC6960]
[RFC6066] で定義されている status_request 拡張と [RFC6961] で定義されている status_request_v2 拡張の両方 (これにより最も広範囲のクライアントとの相互運用性が可能になる可能性があります。)
[RFC6961] で定義されている OCSP stapling 拡張

このセクションの考慮事項は, DANE-TLSA リソースレコード [RFC6698] を使用してクライアントにサーバーが TLS 接続に有効で良好と見なす証明書を通知するシナリオには適用されません。