クライアント証明書の検証が成功した後、HTTP cookie を (関連付けられたサーバー側セッションと共に) 生成します。これは、クライアントによって提供されると、クライアント証明書の検証がスキップされます。
これはまだ安全ですか？(そして、セキュリティとプラグマティズムを最適化するにはどうすればよいでしょうか?)
サーバーは、中間者が存在しないことを自分自身で証明できなくなるため、理論的にはそれほど安全ではありません。
クライアントがクライアント側の証明書を提示すると、サーバーはそれを暗号的に信頼できます。クライアントとサーバーは、クライアントのキーに基づいてデータ (つまり、セッション キー) を暗号化する必要があります。クライアント側の証明書がなければ、サーバーは、クライアントがサーバーの証明書を (クライアントによって認識されるように) 適切に検証したことを期待することしかできません。
すぐに使用できる Windows クライアントは、200 を超えるルート CA 証明書を信頼します。クライアント側の証明書がない場合、サーバーは拡張子によって信頼することになります。
クライアント証明書が MitM に対する防御を提供していることを確認するために、パケット キャプチャで何を探すべきかについての優れた記事を次に示します
。
このタイプの MitM の説明。
http://www.networkworld.com/community/node/31124
この手法は、一部のファイアウォール アプライアンス ボックスで実際に使用され、SSL の詳細な検査を実行します。
MitM は、成功するのに多くの時間を要した、大きなミッション インポッシブル スタイルの作品のように見えていました。実際には、侵害された DNS リゾルバーまたはルーターが途中で必要になることはありません。世の中には、Linksys や Netgear の小さなボックスがたくさんありますが、そのうちの 2 つか 3 つは最新のセキュリティ アップデートが適用されていません。
実際には、大手金融機関のサイトではこれで十分なようですが、最近の証拠によると、大手金融機関のリスク評価戦略は理想的とは言えません。
このスキームの無料の実装はありますか? (私は CA による SiteMinder 製品を認識しています)
クライアント側のクッキーですよね？これは、すべての Web アプリ フレームワークのかなり標準的な部分のようです。
上記を考えると、アプリケーション内での認証を継続する必要がありますか、それともサーバー内に移行する必要がありますか?
ハードウェア暗号アクセラレータ (SSL プロキシ フロント エンドまたはアクセラレータ カードのいずれか) は、この処理を劇的に高速化できます。
証明書の検証を HTTP サーバーに移動すると役立つ場合があります。とにかく、暗号計算で重複をしている可能性があります。
クライアント証明書のアルゴリズムを安価にしたり、キーサイズを小さくしたりすることでメリットがあるかどうかを確認してください。
クライアント証明書を検証したら、そのハッシュ ダイジェスト (またはすべて) を短時間キャッシュしてみてください。これにより、ヒットごとに信頼チェーンのずっと上まで署名の検証を繰り返す必要がなくなる可能性があります。
クライアントとの取引頻度は？トランザクションの大部分を構成しているトランザクションが頻繁に発生する場合は、単一の SSL ネゴシエーション/認証で複数のトランザクションを組み合わせるように説得できる可能性があります。HTTP Keep-Alive ヘッダーの設定を調べてください。彼らはすでにある程度そうしているかもしれません。おそらくあなたのアプリは、すべての HTTP 要求/応答でクライアント証明書の検証を行っているのでしょうか?それとも、各セッションの開始時に 1 回だけでしょうか?
とにかく、これらはいくつかのアイデアです。頑張ってください!