認証とは何ですか？これは、トンネルの反対側にいる誰もがあなたが信じている人であることを確認しています。それは本当にあなたが使いたいidentityの種類に依存します。
ほとんどのWebサイトでは、興味深い概念はcontinuityです。誰が接続しているかは気にしません。確かに、Webサイトのポイントは、everybodyによって読み取れるようにすることです。 Webサイトが達成したいと考える真正性の一種は、2つの連続した要求が実際に同じクライアント（そのクライアントが誰であっても）からのものであることを確認することです。これは、Webサイトのエクスペリエンスが、ユーザーのアクション（ユーザーがクリックするリンク）によって駆動される論理的な一連のページのエクスペリエンスであり、攻撃者が求めているのは、その映画のようなフレームワークを操作することです。ユーザーとWebサイトの設計者はセッションの観点から考えており、攻撃者はセッションをハイジャックしようとしています。
この信頼性は、いくつかのメカニズムによって実現されます。
- 同じクライアントからの連続するHTTP要求は、同じ接続を経由します（「キープアライブ」機能を使用）。
- SSLは、ネゴシエーションされた共有キーを再利用するセッション再開メカニズムを提供します（これは SSL/TLS標準 のセクション7.3で説明されている「短縮ハンドシェイク」です）。
- HTTPリクエストには、サーバーが選択するcookieを含めることができます。通常、ユーザー固有のランダムな値がCookieとしてユーザーに送信され、後続の要求でその値が返されることを確認すると、サーバーは要求が同じユーザーからのものであると確信します。
Cookieは、継続性を確保するために十分です。
クライアント証明書はどのような追加の値を追加しますか？まあ、それほどではありません。 Certificates は、キー/名前バインディングを配布する方法です。クライアント証明書（Webコンテキスト内）が関連するシナリオは主に3つあります。
Webサーバーには、someone elseによって定義されるユーザーIDの拡張概念が必要です。たとえば、市民がアクセスできる政府のサービスを想像してみてください。オンライン選挙システム。明確な名前と生年月日で市民を構成するものは、国全体で管理されますが、サービスを実行している国と同じ部分ではありません。その場合、クライアント証明書は、証明書を発行したPKIから市民に、誰が何を指名されているかを言う資格がまったくないにもかかわらず、誰が接続したかを明確に記録しておく必要があるオンライン選挙システムに認証を転送する方法です。
システム設計者は、既存のWebブラウザーの堅牢性にほとんど信頼を寄せていません。ユーザーのブラウザが乗っ取られた場合、シークレットCookieが盗まれる可能性があり、ユーザーは基本的に永遠に失ってしまいます。一方、ユーザーがスマートカードを使用していて、thatスマートカードに秘密鍵（クライアント証明書と組み合わせて使用される）が格納されている場合、完全なブラウザハイジャックまだ大きな問題ですが、より多くのが含まれています：スマートカードは貴重な秘密鍵を公開せずに、立派な切腹をコミットするため、状況を回復できます。必須のフォーマットと再インストールが実行されると、物事は再び安全になります。
Webサイトは真正性だけでなく、否認防止も取得したいと考えています。否認防止は、システムの技術的な部分からのサポートが必要な法的概念であり、そのサポートは デジタル署名 です。ここでは、SSL/TLSの提供範囲外です。 SSL/TLSクライアント認証は、ユーザーとサーバー自体の間の法的な矛盾を解決するために使用できる証明となることは決してできません（銀行サーバーは接続のトランスクリプトを表示できず、「そのユーザーreallyこれらのアクションをその価格で購入するように依頼されました。」このような場合、クライアント証明書と、証明書を使用して実際のデータに署名するクライアント側コードが必要です。ただし、クライアントに証明書を発行するというハードワークが実行された後は、HTTPSに証明書を使用するだけでも理にかなっています。
Webサーバーの一般的なケースでは、これらのシナリオはいずれも適用されません。したがって、クライアント証明書は使用されません。余分な値を追加しない限り、実際の問題が発生するためです。それが問題を探す解決策になるでしょう。
主な理由は、インターネットユーザーの95％が、クライアント側の証明書とは何か、また証明書の使用方法を知らないためです。一部のユーザーはユーザー名とパスワードをほとんど使用できず、ほとんどのユーザーは2要素認証を気にしません。また、単一のサービスに対する認証のために、クライアント証明書を個別のデバイス（デスクトップ、ラップトップ、タブレット、スマートフォンなど）にインストールするのも面倒です。
だから、簡単なリストのために：
- 無知。人々は、自分が何であるか、なぜ有用なのかを知らないだけです。
- 便利。クライアント証明書を使用するようにデバイスを構成することに煩わされることはありません。
- Support。パスワードを忘れた場合やログインできない場合でも、現在テクニカルサポートに電話をかけなければならない場合、クライアント証明書をインストールする必要がある場合、サポートコールがさらに必要になると想像できますか。 ？この問題は、Internet Explorerの市場シェアの低下によってさらに倍増するため、IE、Firefox、Chrome、Opera、Safariなどのさまざまなモバイルデバイスへのインストールについてユーザーをガイドするように、スタッフをトレーニングする必要があります。
- Complexity。ユーザーアカウントに関連して証明書を検証するには、追加のサーバー側コードが必要です。
- 有病率。主要なサイトがそれらを使用していないen-massので、他の誰も使用しません。私はこれが難点22であることを理解していますが、テクノロジーの採用はよくあります。
- Complacency。ほとんどのベンダーは、それらのベンダーが財務などの非常に機密性の高い/重要な情報を保護している場合でも、パスワード（または2FA）がその目的にとって十分に強力であると想定していますデータ。
したがって、クライアント側の証明書を大規模に見るのはいいことですが、深刻なイベントがベンダーにそれを実行させない限り、実際にそれが起こるのを見ることはありません。
クライアントは、URLで識別される特定のサーバーに到達しようとしています。したがって、クライアントはサーバーを認証する必要があります。
一方、HTTPSのほとんどの使用では、すべてのクライアントがサーバーに接続できます。サーバーは、クライアントを事前に認識していません。したがって、サーバーがクライアントを認証するためのものはありません。サーバーは、クライアントマシンではなく、ユーザーを認証する必要があります。
インターネット設定では、クライアントがプロキシの背後にある、動的IPアドレス上にあるなどの可能性があります。サーバーが確認する必要のあるものはありません。クライアントを認証する唯一のポイントは、法医学的な目的で、または複数の接続にわたってクライアントを追跡するために、将来の使用のためにそのIDを記録することです。ユーザーは複数のマシンから接続する可能性があるため、クライアントマシンの追跡にはあまり意味がありません。クライアントIDを記録することは、悪意のあるクライアントやユーザーを特定するのに非常にわずかしか役に立たない（攻撃者が有用な情報を提供しない証明書を生成した可能性が高い）ので、努力する価値はありません。
既知のクライアントのみがサーバーに接続する必要があるイントラネット設定では、クライアント認証が役立ち、使用されます。