認証の拡張保護は、中間者 (MITM) 攻撃から保護するのに役立ちます。この攻撃では、攻撃者がクライアントの資格情報を傍受してサーバーに転送します。
クライアント、サーバー、攻撃者の 3 人の参加者を含むシナリオを考えてみましょう。 サーバーには URL https://serverがあり、攻撃者には URL https://attackerがあります。 攻撃者は、クライアントを悪用して、サーバーであるかのように攻撃者にアクセスします。 その後、攻撃者はサーバーに要求を送信します。 攻撃者がセキュリティで保護されたリソースにアクセスしようとしている場合、サーバーは WWW-Authenticate ヘッダーを使用して攻撃者に応答します。 攻撃者は認証情報を持っていないので、WWW-Authenticate ヘッダーをクライアントに送信します。 クライアントは Authorization ヘッダーを攻撃者に送信し、攻撃者はそのヘッダーをサーバーに送信し、クライアントの資格情報を使用してセキュリティで保護されたリソースにアクセスします。
現在、クライアント アプリケーションが HTTPS を使用して Kerberos、Digest、または NTLM を使用してサーバーに対して自身を認証すると、トランスポート レベル セキュリティ (TLS) チャネルが最初に確立され、このチャネルを使用して認証が行われます。 ただし、Secure Sockets Layer (SSL) によって生成されたセッション キーと、認証時に生成されるセッション キーの間にはバインディングはありません。 そのため、前のシナリオでは、通信が TLS (HTTPS チャネルなど) 経由で行われる場合、2 つの SSL チャネルが作成されます。1 つはクライアントと攻撃者の間、もう 1 つは攻撃者とサーバーの間です。 クライアントの資格情報は、最初にクライアントと攻撃者の間の SSL チャネルを介してクライアントからサーバーに送信され、次に攻撃者とサーバーの間のチャネル経由で送信されます。 クライアントの資格情報がサーバーに到達すると、サーバーは、それらの資格情報が送信されたチャネルが、クライアントではなく攻撃者から送信されたことを検出せずに資格情報を検証します。
解決策は、TLS で保護された外部チャネルとクライアントが認証した内部チャネルを使用し、チャネル バインド トークン (CBT) をサーバーに渡すことです。 CBT は TLS で保護された外部チャネルのプロパティであり、クライアントが認証した内部チャネルを介して外部チャネルを会話にバインドするために使用されます。
前のシナリオでは、クライアント攻撃者の TLS チャネルの CBT が、サーバーに送信される認証情報とマージされます。 CBT 対応サーバーは、クライアントと攻撃者のチャネルに対応するクライアント認証情報に含まれる CBT と、攻撃者とサーバー チャネルに接続されている CBT を比較します。 CBT はチャネルの宛先に固有であるため、クライアント攻撃者の CBT は攻撃者とサーバーの CBT と一致しません。 これにより、サーバーは MITM 攻撃を検出し、認証要求を拒否できます。
クライアント側では、構成設定は必要ありません。 クライアントがCBTをサーバーに渡せるように更新されると、それ以降は常に渡せるようになります。 サーバーも更新されている場合は、CBT を使用するように構成することも、無視するように構成することもできます。 更新されていない場合は無視されます。
サーバーは、次のレベルの保護を持つことができます。
なし。 チャネル バインド検証は実行されません。 これは、更新されていないすべてのサーバーの動作です。
部分的。 更新されたすべてのクライアントは、サーバーにチャネル バインディング情報を提供する必要があります。 更新されていないクライアントは、更新する必要はありません。 これは、アプリケーションの互換性を可能にする中間オプションです。
一杯。 すべてのクライアントは、チャネル バインディング情報を提供する必要があります。 サーバーは、認証を行わないクライアントからの認証要求を拒否します。
詳細については、Win7 CBT/拡張保護のサンプルを参照してください。