認証の拡張保護の概要
認証時の拡張保護によって、攻撃者がクライアントの資格情報をインターセプトして特定のサーバーに転送する man-in-the-middle (MITM) 攻撃を防ぐことができます。
クライアント、サーバー、および攻撃者の 3 つの参加要素が存在するシナリオについて考えてみます。 サーバーには https://server という URL があり、一方で攻撃者には https://attacker という URL があります。 攻撃者は、自身がサーバーであるかのようにしてクライアントが攻撃者にアクセスするように騙します。 次に、攻撃者はサーバーに要求を送信します。 攻撃者がセキュリティで保護されたリソースへのアクセスを試みると、サーバーは攻撃者に対して WWW 認証ヘッダーで応答します。 攻撃者は認証情報を持っていないため、WWW 認証ヘッダーをクライアントに送信します。 クライアントは攻撃者に WWW 認証ヘッダーを送信し、攻撃者はそのヘッダーをサーバーに送信してクライアントの資格情報を利用してセキュリティで保護されたリソースにアクセスします。
現在のところ、クライアント アプリケーションが 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 を使用するように設定したり、CBT を無視するように設定することもできます。 サーバーを更新しない場合、CBT は無視されます。
サーバーには、次の保護レベルを設定できます。
[なし] : チャネル バインディングの検証は実行されません。 更新されていないすべてのサーバーの動作です。
部分的。 更新されたすべてのクライアントは、サーバーにチャネル バインディング情報を提供する必要があります。 クライアントが更新されていなければ、その必要はありません。 アプリケーションの互換性を許容する中間のオプションです。
完全。 すべてのクライアントがチャネル バインディング情報を提供する必要があります。 サーバーは、クライアントが要求しないクライアントからの認証要求を拒否します。
詳細については、Win7 CBT/拡張保護サンプルを参照してください。