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

6.1. Triple Handshake Preconditions and Impact (トリプルハンドシェイクの前提条件と影響)

トリプルハンドシェイク攻撃を開始する1つの方法は Section 1 で説明されており、攻撃により破られるセキュリティメカニズムについても言及されています。より詳細な議論と図については、[TRIPLE-HS] を参照してください。ここでは、攻撃の前提条件と影響についてさらに議論します。

トリプルハンドシェイク攻撃を開始するには、2つの異なるセッションで同じマスターシークレットを強制できる必要があります。これが発生するには、2つの前提条件を満たす必要があります。

クライアント C は、悪意のあるサーバー A に接続する意思がなければなりません。ウェブなどの特定のコンテキストでは、ブラウザに信頼できないオリジンからコンテンツをロードするように指示できるため、これは簡単に実現できます。
プレマスターシークレットは、2つのセッションで同期されている必要があります。これは、RSA および DHE 鍵交換で特に簡単に実現できますが、特定の条件下では、ECDHE、SRP、および PSK 鍵交換もこのために悪用される可能性があります。

マスターシークレットが2つのセッションで同期されると、マスターシークレットの一意性に依存するセキュリティプロパティはすべて侵害されます。たとえば、TLS エクスポーター [RFC5705] は、現在のセッションにバインドされた一意の鍵を提供しなくなります。

TLS セッション再開も、再開するピアを認証するためにマスターシークレットの一意性に依存しています。したがって、同期されたセッションが再開されると、ピアはお互いの身元を確認できず、攻撃者は接続キーを知っています。明らかに、この攻撃ステップの前提条件は、クライアントとサーバーの両方が（セッション識別子またはセッションチケット [RFC5077] を介して）セッション再開をサポートしていることです。

さらに、同期された簡略化されたハンドシェイクでは、トランスクリプト全体（verify_data 値を含む）が同期されます。したがって、簡略化されたハンドシェイクの後、"tls-unique" [RFC5929] などのチャネルバインディングは接続を一意に識別しなくなります。

簡略化されたハンドシェイクでの verify_data の同期は、再ネゴシエーション指示拡張 [RFC5746] のセキュリティ保証も弱体化させ、再ネゴシエーション攻撃 [Ray09] に似たプレフィックス注入の欠陥を再び有効にします。ただし、トリプルハンドシェイク攻撃では、クライアントはサーバー証明書が異なる完全なハンドシェイク間で変更されるのを確認します。したがって、この段階の攻撃を開始するための前提条件は、共通名が一致しない場合でも、クライアントが各ハンドシェイクで異なる証明書を受け入れることです。トリプルハンドシェイク攻撃が発見される前は、これは少なくとも一部の Web ブラウザでは一般的な動作でした。したがって、そのようなブラウザは攻撃に対して脆弱でした。

拡張マスターシークレット拡張は、異なるセッションが必然的に異なるマスターシークレット値になることを保証することにより、最初の段階でトリプルハンドシェイク攻撃を阻止します。したがって、マスターシークレットの一意性に依存するすべてのセキュリティプロパティが保持されることが期待されます。特に、TLS セッションが拡張マスターシークレット拡張によって保護されている場合、それを再開し、チャネルバインディングを使用し、再ネゴシエーション全体で証明書の変更を許可することは安全であり、すべての証明書が同じピアによって制御されていることを意味します。拡張マスターシークレット拡張を正当化する記号暗号プロトコル分析は、[VERIFIED-BINDINGS] に表示されます。

6.2. Cryptographic Properties of the Hash Function (ハッシュ関数の暗号化プロパティ)

2つの異なるセッションのセッションハッシュは異なる必要があります。したがって、session_hash の計算に使用される Hash 関数は、衝突耐性がある必要があります。そのため、MD5 や SHA1 などのハッシュ関数は推奨されません (NOT RECOMMENDED)。

Finished メッセージ計算で使用される Hash 関数は、再ネゴシエーション指示拡張 [RFC5746] が機能するためにすでに衝突耐性が必要であることに注意してください。これは、ハンドシェイクメッセージ（したがって verify_data）での意味のある衝突が再ネゴシエーション攻撃 [Ray09] を再び有効にする可能性があるためです。

セッションハッシュの計算に使用されるハッシュ関数は、TLS プロトコルのバージョンによって異なります。TLS 1.2 に定義されているすべての現在の暗号スイートは SHA256 以上を使用しており、セッションハッシュも同様です。プロトコルの以前のバージョンの場合、MD5 と SHA1 のみがサポートされていると想定でき、このドキュメントでは、レガシー実装に新しいハッシュ関数のサポートを追加することを要求していません。これらのバージョンでは、セッションハッシュは Finished メッセージと同様に MD5 と SHA1 の連結を使用します。

6.3. Handshake Messages Included in the Session Hash (セッションハッシュに含まれるハンドシェイクメッセージ)

session_hash は、暗号スイートのネゴシエーション、鍵交換メッセージ、およびクライアントとサーバーの ID を含む、すべての関連するセッション情報を網羅することを目的としています。ハッシュは拡張マスターシークレットを計算するために必要であるため、Finished メッセージの前に利用可能である必要があります。

このドキュメントでは、session_hash が ClientKeyExchange までのすべてのハンドシェイクメッセージをカバーするように設定しています。既存の TLS 暗号スイートの場合、これらのメッセージには新しいセッションのすべての重要なコンテンツが含まれています (CertificateVerify はセッションコンテンツを変更しません)。同時に、これにより、プレマスターシークレットの直後に拡張マスターシークレットを計算できるため、実装は一時的なプレマスターシークレットをできるだけ早くメモリから破棄できます。

新しい暗号スイートまたは TLS 拡張には、ClientKeyExchange と Finished の間に重要なセッションコンテキストを追加する追加のメッセージが含まれる可能性があります。そのような場合、この仕様のセキュリティ保証の一部が適用されなくなり、新しい中間者攻撃が可能になる可能性があります。たとえば、クライアントとサーバーがセッションチケット拡張 [RFC5077] をサポートしている場合、セッションハッシュはサーバーから送信された新しいセッションチケットをカバーしません。したがって、中間者は、クライアントに現在のセッション用ではないセッションチケットを保存させることができる可能性があります。このベクトルに基づく攻撃はまだ知られていませんが、セッションハッシュでカバーされているものを超えてセッションチケットに追加情報を保存するアプリケーションには、慎重な分析が必要です。

6.4. No SSL 3.0 Support (SSL 3.0 サポートなし)

Secure Sockets Layer (SSL) プロトコルバージョン 3.0 [RFC6101] は TLS プロトコルの前身であり、現在では弱いと見なされている時代遅れの暗号化構造の使用に起因する他の脆弱性とともに、トリプルハンドシェイク攻撃に対しても同様に脆弱です。SSL 3.0 は廃止されました [RFC7568]。

このドキュメントで説明されている対策は TLS 拡張に依存しているため、SSL 3.0 では使用できません。このドキュメントを実装するクライアントとサーバーは、SSL 3.0 ハンドシェイクを拒否すべきです (SHOULD)。SSL 3.0 のサポートを選択した場合、結果のセッションはレガシーマスターシークレット計算を使用しなければならず (MUST)、Section 5.4 の相互運用性に関する考慮事項が適用されます。