SSLクライアント証明書の検証の最適化

Question

現在、さまざまなクライアントの種類と役割に対する一連のWebサービス公開インターフェイスが用意されています。

背景：

• 認証がSSLクライアント証明書の検証を介して処理されます。これはです。現在はがWebサービスコードで実行されています（HTTPサーバーではありません）。私たちはこれより安全性の低いスキームを使用したくありません。この投稿は認可についてのみではなく、認証についての話ではありません。
• WebサービスはSOAPとREST（JSON）の両方を話します。どちらのアプローチのメリットについても議論を開始することには興味がありません。
• Webサービスを介して公開されるすべての操作は、ステートレスです。

私の問題は、各リクエストのクライアント証明書を検証することは非常に重く、アプリケーションサーバー上のCPU時間を簡単に支配することです。私はすでに負荷を軽減するために、認証の&アプリケーション部分を別の物理サーバーに分けることを試みましたが、全体的なディスパッチ速度は改善されません - 要求がどこで行われても依然として認証に一定の時間がかかります。

クライアント証明書の検証が成功した後にHTTP Cookie（関連するサーバー側セッションとともに）を生成することで、認証の数を制限しようとしています。クライアント証明書の検証により、クライアント証明書の検証がスキップされますまだSSLで話しています）。また、セッションをタイムリミットし、プロセスをクライアントの観点からできるだけ透明にしたいと思っています。

私の質問：

1. これはまだのように安全ですか？ （セキュリティと実用性のために最適化するにはどうすればよいでしょうか）
2. このスキームは無料で実装されていますか？ （私はCAのSiteMinder製品に気付いています）
3. 上記のことを考えれば、引き続きアプリケーション内で認証を行うか、またはサーバー内に移行する必要がありますか？ により供給されたとき、クライアントは、クライアント 証明書の検証が

   をスキップされるようになります 成功したクライアント証明書 検証、後（ 関連するサーバー側のセッションで）HTTPクッキーを生成

Answer 1

これはまだ安全ですか？ （そしてどのように我々は、セキュリティと プラグマティズムのため 最適化することができますか？）

サーバーは、もはやのman-in-the-middleが存在しないことを自分自身に証明することができますので、それは理論的にはそれほど安全ではありませんません。

クライアントがクライアント側の証明書を提示すると、サーバーはそれを暗号的に信頼することができます。クライアントとサーバーは、クライアントのキーに基づいて暗号化とデータ（セッションキー）を提供する必要があります。クライアント側の証明書がなければ、サーバーは、クライアントがサーバーの証明書を検証して（クライアントが認識している）良い仕事をしていることを願っているだけで、MitM氏の可能性が排除されます。

すぐに使用できるWindowsクライアントは、200を超えるルートCA証明書を信頼します。クライアント側の証明書がない場合、サーバーは拡張機能によって信頼できる状態になります。ここで

は、クライアント証明書がなMitMに対する防御を提供していることを確認するために、パケットキャプチャで検索する内容のすてきな過去記事です：のMitMのこのタイプの http://www.carbonwind.net/ISA/ACaseofMITM/ACaseofMITMpart3.htm

説明。 http://www.networkworld.com/community/node/31124

このテクニックは、実際には一部のファイアウォールアプライアンスボックスでSSLの詳細な検査を実行するために使用されます。

MitMは大きなミッションのように見えました。実際には途中でどこかのDNSリゾルバやルータを奪取することはありません。世界にはLinksysとNetgearの箱がたくさんあります。おそらく2〜3つに最新のセキュリティアップデートがありません。

実際には、これは大手金融機関のサイトにとっては十分だと思われますが、最近の証拠によると、リスクアセスメント戦略は幾分理想的ではありません。

このスキームは無料で実装されていますか？ （私はCAのSiteMinder製品を認識しています）

クライアント側のクッキー、そうですか？これは、すべてのWebアプリケーションフレームワークのかなり標準的な部分であるようです。

上記を前提として、引き続きIn-application認証を行うか、またはサーバー内に移行する必要がありますか？

ハードウェア暗号アクセラレータ（SSLプロキシフロントエンドまたはアクセラレータカードのいずれか）を使用すると、この処理が大幅に高速化されます。

証明書の検証をHTTPサーバーに移動すると役立ちます。とにかく暗号の数学で重複しているかもしれません。

クライアントの証明書で、より安いアルゴリズムや小さいキーサイズのメリットがあるかどうかを確認してください。

クライアント証明書を検証したら、その証明書のハッシュダイジェスト（またはすべてのもの）を短時間キャッシュすることができます。これにより、すべてのヒットで信頼の連鎖を超えてシグネチャの検証を繰り返す必要がなくなります。

お客様の取引頻度は？大量のトランザクションを構成するトランザクションが頻繁に発生する場合は、単一のSSLネゴシエーション/認証で複数のトランザクションを結合するように説得することができます。 HTTPキープアライブヘッダーの設定を調べます。彼らはすでにある程度それをしているかもしれません。おそらく、あなたのアプリはすべてのHTTPリクエスト/レスポンスでクライアント証明書の検証を行っているのでしょうか？

とにかく、それらはいくつかのアイデアです、最高の運がいいです！