SSLを使用した双方向認証はどのように機能しますか？
アリスがボブでWebサービスを使用したいとします。
ボブはbob.in.wonderland.comにいます
アリスはbob.in.wonderland.com:443への接続を開きます。 DNS magic rabbitによって取得されたアリスは、ポート443の69.64.156.40に到着します。
アリスは証明書を要求し、ボブはDiginotarが発行した証明書をbob.in.wonderland.comに提示します。アリスはDiginotarを信頼しているので、彼女が確かにボブと話していることは非常に確実です。
しかし、ボブはアリスがホワイトリストに含まれているかどうかを確認したいと考えています。
今のところ、ボブが知っているのは、IPアドレス66.147.244.191から接続を受け取ったことだけです。
彼は証明書を要求し、Verisignがalice.in.wonderland.comに対して発行した証明書を提示されます。
ボブは今何をしていますか？
66.147.244.191に逆引きDNSを作成して、それがalice.in.wonderland.comと呼ばれているかどうかを確認しますか？
AliceがSquidプロキシの背後にある場合はどうなりますか？
脅威モデルは、アリスとボブの間にman-in-the-middle攻撃が存在する可能性があり、アリスとボブが同じ信頼できるサブネット上にないことを想定しています。これがSSL/TLSを保護するために設計されたものであり、そのため、アリスはあなたの例で（少なくとも）ボブの証明書をチェックする必要があります。
ボブの観点からは、アリスのリクエストが既知のIPアドレスからのものであることを確認することはあまり役に立ちません。攻撃者はパケットを偽造および変更して、希望するIPアドレスから送信されたように見せかけることができます。その後、DNSルックアップも役に立たなくなります。正しいDNSエントリでIPアドレスを使用するようにパケットを偽造することを確認するだけで十分です。
BobがSSL/TLSハンドシェイク中にAliceにクライアント証明書を要求すると、これにより、Aliceは証明書を送信し、SSL/TLSハンドシェイク中に秘密鍵を使用してIDをアサートします。ハンドシェイクが正常に完了すると、ボブはアリスがその証明書の秘密鍵を持っていることを認識し、アリスがこの証明書を信頼していることを確認する必要があります。
SSL/TLSを使用している場合、リクエストがプロキシの背後から来ているかどうかは関係ありません。 HTTPプロキシは、SSL/TLS接続を元のクライアントからターゲットサーバーにトンネルするだけです。
ボブにとって重要なのは、アリスの証明書をどのように検証するかです。通常、これは、AliceがBobの証明書を検証したのと同じ方法でPKIを使用して行われますが、これはBobと同じCAである必要はありません（Bobが信頼するものである必要があります）。これはPKIを使用する必要もないことに注意してください。特定のリストに対して証明書を検証することは可能ですが（たとえば、アリスとボブが以前に会った場合）、ボブは送信する承認済み発行者リストを微調整する必要がある場合があるため（たとえば、空のリストを送信する、これはTLS 1.1で明示的に許可されていますが、以前のバージョンではどちらの方法でも指定されていません。 Certificate Request message ）を参照し、カスタムコードを使用してその証明書を確認してください。 （私は過去にこの種のスキームを実装したことがあり、うまく機能します。）
「MITMプロキシサーバー」と呼ばれるものを使用する場合、これには例外があります。つまり、独自の証明書を挿入して実際のSSL/TLSサーバーを偽装するように構成されたプロキシサーバーです（ SquidのSSLバンプ）を参照 =）。この場合、アリスが見る証明書はDiginotarからではなく、別のCA（通常、これが企業LANで行われる場合の企業CA）からのものです。
アリスは自分がそのようなMITMプロキシを信頼することを許可する場合がありますが、SSL/TLSクライアント証明書認証を使用すると、ボブはMITMがあることを認識し、接続は失敗します。これは、Aliceが CertificateVerify メッセージでSSL/TLSハンドシェイク全体（AliceとBobの両方に表示）に署名して、クライアント証明書で認証することになっているためです。 MITMプロキシがボブの証明書を置き換えるため、アリスとボブから送信された署名は一致しません。
特定の実装によって異なります。
一般に、アリスはボブのクライアントとして行動します。 Bobが他の承認されたサーバーのみの接続を期待している場合、Bobは発行者のCRLに対して、有効期限を含む有効性について証明書をチェックし、名前に対して逆引きを実行します。ボブがユーザークライアントを期待している場合、逆引きはおそらくスキップされるか、ロギングにのみ使用されます。
ボブがアリスが既知の信頼できるホストから接続することを期待している場合、ボブはアリスのIPアドレスがDNSレコードと一致することを期待します。 Aliceがプロキシの背後にあることはBobにとって重要ではなく、BobはプロキシのIPアドレスのみを認識します。そう alice.in.wonderland.comは、プロキシの外部IPアドレスに設定する必要があります。
ただし、重要な部分は次のとおりです。
- ボブは、アリスの公開鍵を、ボブのリソースへのアクセスを許可するために使用されるある種のIDにすでにマップされています。
- ボブとアリスは、お互いに秘密鍵でのみ復号化できるメッセージを互いに送信し合うように挑戦します。このようにして、両者が既知で信頼できる証明書を持っていることを証明します。
また、次の点に注意してください：アリスがプロキシの背後にある場合、プロキシはアリスの秘密鍵を持っている必要があります（プロキシがアリスの代わりにボブと通信できるようにする）、または内容を変更せずにアリスの接続を通過する必要があります。
追加のリファレンス http://en.wikipedia.org/wiki/Transport_Layer_Security または特定の技術的な詳細については http://tools.ietf.org/html/rfc5246 。
お役に立てば幸いです。
結構です。 SSLハンドシェイクが完了すると、ボブは、ベリサインがalice.in.wonderland.comとして認定した人物と話していることがわかります。この時点でボブがこの情報をどのように処理するかは彼次第であり、特定のアプリケーションに依存します。いくつかの例：
ボブは、接続を許可されたクライアントのホワイトリストを持っている可能性があります。次に、ボブはこのリストで
alice.in.wonderland.comを検索します。 （代わりに、ボブは公開鍵のホワイトリストを持つことができますが、クライアント証明書により、ボブはホワイトリストに人間が読める値を入力できるようになるため、管理が容易になる場合があります。）ボブは
alice.in.wonderland.comをアリスのユーザー名として扱い、彼女のアカウントにログインする可能性があります。つまり、ボブはユーザーのリストを含むデータベースを持っている可能性があります。ユーザーごとに、ユーザーの名前（ユーザーの証明書にある）とそのユーザーに関連付けられているすべての情報が含まれます。 Bobは、Nという名前の人から接続を受信すると、テーブルでNを検索し、クライアントをNとして自動的にログインできます。誰かが新しいアカウントを作成すると、Bobは証明書にある名前で新しいアカウントを自動的に作成できます（まだ存在していないと仮定します）。その結果、ユーザーはユーザー名やパスワードを入力しなくても、Bobのサービスにログインできます。それらのクライアント証明書は、それらを認証するために使用されます。
繰り返しますが、これはアプリケーションに依存します。それは、ボブが話しているコンピューターのIDについてボブが何を知りたいかによって異なります。単一の答えはありません。