パケットインスペクションのDiffie-Hellman暗号を無効にするには、どうすれば安全ですか。
今日市場に出回っている多くのネットワークパケットモニタリングツールには、以下に説明する推奨構成パラメーターとほぼ同じものが含まれているようです。
本質的に、ApacheまたはIIS=のネットワークモニタリングは、ApacheでDiffie-Hellman暗号が無効にされていない限り、TLSトラフィックでは機能しないと主張します。 ？この場合、キー交換はどのようにして安全に行われますか？
たとえば、Apacheが鍵の交換に別の非対称暗号スイートを使用している場合、Diffie-Hellmanを無効にすると、ここで監視ツールに何が提供されますか？
TL、DR：この製品を推奨どおりに厳密に使用すると、コンプライアンスルールに違反する可能性があります。これはDiffie-Hellmanの側面が原因ではありませんが、DHの側面が安全でないアーキテクチャを示していることや、ドキュメントの他の側面がセキュリティに対する懸念のひどい欠如を示していることから、私はまだそれを使用しません。
TLSハンドシェイクが機能する方法はいくつかあります。サーバーはだれとでも話そうとするが、クライアントは特定のサーバーと話をしたいという一般的なケースを考えると、ハンドシェイクには2つの機能上の目標があります。
- クライアントが目的のサーバーと通信していることを確認できるようにします。
- 2つのパーティがセッションキー（キー交換部分）について合意することを許可します。
鍵交換にはセキュリティ上の目標があります。つまり、通信を監視および変更できる man-in-the-middle はサーバーになりすますことができません。または、セッションキーを取得します。
[〜＃のおかげで、サーバーはまずその公開鍵をクライアントに送信し、さらにクライアントが公開鍵がこのサーバーにとって正しいものであることを確認できるようにするいくつかの追加データ（証明書）を送信します〜] pki [〜＃〜] 。この段階では、クライアントは正当なサーバーの公開キーを知っています（または、偽のキーが送信されたことを検出して接続を閉じます）が、攻撃者がデータを変更した可能性があるため、クライアントは受信したものを信頼できません。 。
この後、3つの方法があります。 （さらに詳しく TLSでどのキー交換メカニズムを使用する必要があるか？ を参照してください。）
- 暗号化：クライアントはセッションキーを生成し、それを正当なサーバーの公開キー（PKIによって確認済み）で暗号化します。正当なサーバーだけがそれを検出できますが、中間者はサーバーの秘密キーを持っていないため検出できません。これは、 name に
RSAが含まれているがDHEが含まれていない暗号スイートで発生します。 ApacheのカテゴリRSAは、これらの暗号スイートを示します。 - 署名：クライアントとサーバーは、 Diffie-Hellman を使用して、両方の側が同じセッションキーを計算できるようにデータを交換しますが、中間者が意図したセッションキーを見つけることができません。ただし、中間者の攻撃者は、データを変更して、攻撃者が知っている異なるセッションキーを双方が計算するようにすることができます。これを回避するために、サーバーはハンドシェイク中にデータ交換の署名を送信します。これにより、クライアントがこの署名を確認したときに、サーバーが同じデータを使用してセッションキーを生成したことがわかります。攻撃者はサーバーの秘密鍵を知らないため、この署名を偽造することはできません。これは、 name （
DHEを含む）にECDHEが含まれる暗号スイートで発生します。EのDHEは「エフェメラル」を意味します。これは、Diffie-Hellmanアルゴリズムが使い捨てのセッションキーの生成に使用されるためです。署名部分はRSAまたはECDSAの場合があります。 ApacheのカテゴリEDHは、これらの暗号スイートを示します。 - 鍵交換：静的Diffie-Hellman秘密鍵を使用する暗号スイートがありますが、基本的に誰も使用しないため、これ以上は説明しません。
次に、攻撃者がトラフィックを監視できてもトラフィックを変更できず、さらにサーバーの秘密鍵を知っている場合にどうなるかを考えます。最初の方法では、暗号化されたセッションキーを含むパケットを復号化できます。 2番目の方法では、何もできません。サーバーの署名キーを知っているアクティブな攻撃者は、ハンドシェイク中にサーバーを偽装できます。これにより、サーバーと攻撃者間の有効なTLSセッション、および攻撃者とクライアント間の別の有効なTLSセッションが発生します。しかし、トラフィックを変更できない、または変更しない攻撃者はこれを行うことができません。
2番目のメソッドのこのプロパティは perfect forward secrecy （PFS）と呼ばれます。これは、攻撃者がトラフィックを記録し、後でサーバーのキーを取得する場合、記録されたトラフィックを解読することはできません。 Diffie-Hellman鍵交換の秘密の部分を知る必要がありますが、参加者はハンドシェイクが終了するとすぐにそれらを消去します。
そのミドルボックスは、サーバーが処理しているトラフィックを監視したいが、アクティブに転送したくないようです。それはサーバーの秘密鍵を知る必要があるでしょう、さもなければ全体は無意味です。したがって、指示は、エフェメラルDiffie-Hellmanを使用するすべての暗号スイート、つまりPFSを使用するすべての暗号スイートを無効にし、RSA暗号スイートのみを保持することです。
これはセキュリティを低下させるため、トラフィックを監視するためのひどい方法です。 TLSの基本的なセキュリティを確保するためにPFSは必要ありませんが、侵害された秘密鍵の影響を制限するため、これは良いことです。特に、対応する証明書の有効期限が切れたり失効したりすると、秘密鍵は役に立たなくなります（クライアントが有効期限と失効を正しく確認していると仮定します）。 PFSがない場合、漏洩した古いバックアップにより、古いトラフィックを復号化できます。さらに、このセットアップでは、サーバーの秘密キーを別のボックスにコピーする必要があるため、秘密キーが漏洩するリスクが高まります。
トラフィックを監視する適切な場所は、アプリケーションとTLSエンドポイントの間のサーバー自体です。この製品は、展開が容易になるようにこのように設計されていると思いますが、ひどい設計です。
これらの手順では、PFSを無効にするだけでなく、エクスポート暗号、単一DESなどの低セキュリティ暗号、SSLv2も有効にします。この製品が何歳かはわかりませんが、Apache 2.2とRHEL4（製品のWebページに記載）が出た2005年でさえ、3つすべては時代遅れであり、本当に話さなければならない場合にのみ有効にすることができました古代のクライアントに。これら3つのうちいずれかを今日有効にすると、暗号コンプライアンス標準に違反することになります。