誰かがクライアントブラウザ証明書を使用していますか？
クライアントブラウザの証明書は、侵入者からサイトを保護するための優れた方法のようです。推測することは不可能であり、盗むのは困難です。もちろん、すべての問題を解決するわけではありませんが、セキュリティを強化します。
しかし、それらを使用している公開サイトには遭遇しませんでした。それらを使用するサイトはありますか？セキュリティが重要な場合でも、使用を妨げる欠陥や、使用量が非常に少ないその他の理由はありますか？
認定されたクライアント側では、十分なコスト/メリットのトレードオフがありませんでした。ユーザーを混乱させるため、サポートコストが増加します。そして、それらはまだほんの一部であるため、「知っているもの」であり、ブラウザに対するさまざまなソフトウェア攻撃、配布スキーム、フィッシングなどに対して脆弱です。
優れた認証には、ハードウェアトークンスキーム（2要素認証）が適しています。フェデレーションされている可能性があり、ハードウェアトークンによってサポートされている可能性のあるシングルサインオン（SSO）スキームは、より多くの問題を解決し、展開が容易です。
多くの証明書の管理は、現在の厄介な複数パスワードの問題よりもはるかにユーザーにとって複雑であり、ブラウザは適切な証明書を選択するための適切なサポートを提供していません。また、ユーザーが多数のサイトに単一の証明書を使用する場合、証明書の使用によりユーザーが識別されるため、プライバシーの問題があります。
何十年にもわたって、私たちの多くは、エンドユーザーのPK-cryptoの時代が間近に迫っていると考えてきました。それが進化した方法、ヘルプデスクと開発のコスト、微妙さ、複雑さ、そして現実のPKIの法的な絡み合いがメリットを使い続けていることがわかります。
機器はビットよりも高価に見えますが、ビットが機能しない場合や、ビットを効果的に使用すると生産性が損なわれる場合はそうではありません。
私は少数のサイトでブラウザ証明書を使用していますが、おっしゃるように、主にnotパブリックサイトです。
クライアント側の証明書の主な問題は配布それらです。つまり、私が知らない場合に、システムへのアクセスを許可する「強力な」証明書を安全に提供するにはどうすればよいですか？
企業システムはもちろん、パートナーの小さなサークルに開かれたシステムと同様に、より簡単です。しかし、鍵の配布は常に解決するのが難しいパズルです。秘密鍵の側面と証明書の保護を考慮すると、2つのパーティ間でパスワードを共有するだけよりもはるかに困難です。
もちろん、実際にはある解決策があり、私は「公開」ウェブサイトにもそれを使用しています。 （たまたまアイデンティティビジネスにいるので、彼らにとってオーバーヘッドの価値がある...）。その解決策は、パスワードによるプライマリ認証に基づいており、完全に認証された後、証明書をダウンロードするオプションがあります。
そうではありませんずっとパスワードチャネルがまだ開いているので、より良いです...しかし、少なくとも、パスワードを不可能なものや使用できないものに変更する可能性があり、CSCしかありません。 ...
しかし、これは簡単なことではなく、正しく実装するのはちょっと複雑です。ディストリビューションは依然としてほとんどのユーザーを悩ませます。
私が理解しているように、実際にクライアント証明書を使用することには多くの問題があります。これが私が聞いた問題のいくつかです：
クライアント証明書を取得しています。そもそも最初にクライアント証明書を取得するのはユーザーにとって苦痛です。明らかに、サイトは、ユーザーがサイトの使用を開始する前にジャンプしなければならない不必要なハードルを作りたくないのです。 （サイトがクライアント証明書を生成してクライアントに提供する場合でも、ユーザーにとってなじみのある操作ではありません。セキュリティの問題があることは言うまでもありません。理想的には、クライアントだけがクライアントの秘密鍵を知っている必要があるためです。）最新のブラウザー秘密鍵とクライアント証明書を作成またはインポートする方法を提供しますが、ユーザーエクスペリエンスは恐ろしいものです。
一部のサーバーはクライアント証明書をうまくサポートしていないようです（例：
http://osdir.com/ml/encryption.cryptlib/2005-09/msg00000.html）。移動性が問題です。それらすべての問題にもかかわらず、パスワードは非常に移植可能です。クライアント証明書はそうではありません。クライアントが秘密鍵を生成してクライアント証明書を取得したとしても、2台目のコンピューターの使用を開始したい場合は、複雑で紛らわしいダンスを実行して秘密鍵と証明書を2台目のコンピューターに転送する必要があります。コンピューター。最初のコンピューターが停止した（またはハードディスクの障害が発生した）場合、OSを再インストールするか新しいコンピューターを購入する必要があり、クライアントが秘密キーをバックアップしていない場合、秘密キーを配置する方法がありません。新しいコンピューターにキーと証明書を入力します。彼らはかなりねじ込まれています。サイトは認証のバックアップ方法を作成できるため、秘密キーを紛失したユーザーは新しい秘密キーを生成して送信できますが、この認証のバックアップ方法はチェーン内の最も弱いリンクになる可能性があります。バックアップ方法が簡単に無効になる場合は、認証の主要な方法がどれほど強力であってもかまいません。
ブラウザからクライアント証明書が十分にサポートされているかどうかは不明です。そこにあるさまざまなブラウザー（モバイルブラウザーを含む）がすべてクライアント証明書を適切にサポートしているかどうかはわかりません。
とにかく、PKIモデルはかなりうまく機能していません。 CAがクライアント証明書を与える前にCAがユーザーの身元（本名など）を検証することを想定し、プロトコルはこの想定に基づいて設計されました。ただし、今日のCAは本当の身元を確認しません。これにより、設計の前提と現実との間に不一致が生じます。
クライアント証明書は、ユーザーに プライバシーリスク を作成します。一部のブラウザでは、ドメイン全体のユーザーを追跡できます。 （すべてのブラウザーは、Cookieがこの脅威を慎重に防御することを保証します。Cookieを設定したドメインのみがそれを読み取ることができます。ただし、ブラウザーにはSSLクライアント証明書に対する同様の保護が組み込まれていません。）最近のブラウザーがこれに効果的に対処したかどうかはわかりません問題ですが、私が知る限り、クライアント証明書は比較的未熟な領域です。
クライアントが独自のクライアント証明書を生成して署名した場合、厄介な技術的な問題があります。 TLSプロトコルによると、サーバーは最初に受け入れてもよいCAのリストを要求することになっています。その後、クライアントは、そのCAが発行したクライアント証明書があれば、その証明書で応答します。 （これは、クライアントがHTTPリクエスト、HTTP Cookie、ユーザー名、またはその他の識別情報を送信する前に発生します。）これは、クライアントが発行した（自己署名）クライアント証明書を使用する場合、サーバーは、クライアントがそれ自体を認証または識別する前に、クライアントが使用しているCAの名前を知っている必要があります。それはトリッキーです。
最後に、パイのチェリー：クライアント証明書はフィッシング問題を解決しません。それらはクライアントの秘密鍵の盗難を防ぎますが、他の個人情報は防ぎません。悪意のあるユーザーは、偽の銀行サイトをセットアップすることができます（送信されたクライアント証明書はすべて破棄されます）。フィッシングサイトはユーザーの秘密鍵を学習しませんが、ユーザーが実際の銀行サイトに接続したと考えた場合、銀行口座番号、SSN、PINなどを入力して、攻撃者にその情報を公開する可能性があります。
これらはすべて、使いやすさの低下とサポートコストの増加（ヘルプデスクへの問い合わせなど）につながります。つまり、少なくとも原則として、クライアント証明書を使用できます。それは、実際にはそうすることは誰にとっても不便であり、ユーザビリティはひどいことです。
より根本的に、鶏と卵の問題があります。多くのサイトがクライアント証明書の使用を開始するまで、ブラウザメーカーはクライアント証明書を使用可能にすることを優先しません。そして、ブラウザーがクライアント証明書を使用可能にするまで、サイトはそれらを採用しません。言い換えると、クライアント証明書を使用して一般的な認証の問題を解決したい場合は、すべてのブラウザメーカーに大きな変更を加えるよう両方に説得する必要があります。ブラウザに、およびサイトに新しいテクノロジーを採用するよう説得します。これらすべての当事者が調整された変更を行うまで、誰にもメリットはありません。それは採用への大きな障害です。
HTTPS、安全な永続的なCookie、および電子メールベースの回復を含む、Webでの安全な認証のためのより良いソリューションがあります。しかし、それはあなたの質問の範囲を超えています。
最後のコメント：安全なWeb認証における基本的な課題は、使いやすさ、使いやすさ、使いやすさです。ユーザーにとって適切に機能し、一般ユーザーが使用する可能性が高いため、安全であるシステムを作成することは非常に困難であり、すべてが重要です。暗号はこの問題のほんの一部です。
平均的な人（つまり、あなたがこの質問をしているのであなたではない）はその使用法を理解できないため、主にそれらは使用されていないと思います。それらを使用する商用サイトはいくつかありますが、それらは通常、非常に特別な目的または自動化のためのものです。たとえば、Oracleはクライアント証明書を使用して、パッケージ更新の有効なサポート契約を持つエンドユーザーを検証します。しかし、非常に技術的なユーザーであっても、適切な鍵交換を行うことは困難な場合があります。
そうは言っても、私はクライアント証明書を使用して、公開しているWebサイトの一部を保護しています。これらは素晴らしいと思います。
エストニア国民IDカード は、クライアント証明書が埋め込まれたスマートカードです。スマートカードリーダーを入手して自宅で使用し、政府サービスを申請したり、エストニアの主要銀行に認証したりできます。ユーザーに表示されるのは、カード/ピンプロンプトと、認証されたことがわかっていることだけです。
クライアントの1つは、クライアント証明書を使用してタッチスクリーンキオスクシステムを認証します。システムはディーラーに配布され、それぞれにCAルート証明書と固有のクライアント証明書がインストールされます。
クライアント証明書は、販売店がデバイスの起動時に手動認証を実行する必要なく、Webサーバーに対してキオスクシステムを認証するために使用されます。個々のシステムをシャットダウンする必要がある場合、クライアントが証明書を取り消すのは簡単です。
フランス経済大臣は、ユーザー認証にSSL証明書を使用する税務管理（オンライン納税、期限に関する情報、フォームのダウンロードなど）のための公開Webサイトを公開しました。 AviD♦によってそのようなプロジェクトの主な難点であると指摘されたユーザー登録（この役割はPKIのRegistration Authorityに起因します）は、この管理がすでに十分な情報を持っているので解決されました納税者を特定します。
ブラウザ証明書のバリエーションは、HTTP/SベースのActiveSyncプロトコルで使用されます。
一部の電子メール管理者は証明書を使用してモバイルデバイスを認証し、ユーザーがパスワードを変更したときにモバイル電子メールが突然機能を停止しないようにします。
クライアント証明書は、認証に関して最高の品質を備えています。しかし、ニワトリと卵の問題があるため、ユーザーが真剣な証明書を取得する理由はありません（配信は対面での操作であるため、費用と時間がかかります）。サイトを使用するサイトはほとんどないため、サイト管理者が積極的にサポートする理由はありません。通常、ユーザーには証明書がありません。
セキュリティ要件が十分に高い場合、PKIインフラストラクチャのグローバルコストは完全に予測可能であるため、企業システムは異なります。
しかし、（パスポートではなく）国民IDカードの実際の総コストと手順を覚えている場合、国の行政機関によって確立された証明書を追加しても、それほど多くは追加されず、行政機関などの機関サイトでのすべての認証の質問がうまく解決されます。銀行、...もちろん、私はそれを商人サイトやほとんど管理されていないフォーラムには使用しません
スマートカード認証を提供するサイトの開発に取り組んでいます。ユーザーはUSBカードリーダーを接続してサイトにアクセスし、ログインするときにカードを挿入してPINを入力します。問題は、システムがJavaアプレットを使用しており、これらのアプレットがChromeまたはMS Edgeでサポートされなくなったことです。 Javaアプレットを使用しない新しいミドルウェアが開発されており、すべての主要ブラウザがJavaアプレットとPCのハードウェアとの相互作用を将来停止するのを見ることができるため、これは時間との戦いです。 。
OPスコープを拡張してブラウザーを通過する場合。クライアント証明書は、ブラウザ以外のコンテキストでも使用できます。たとえば、DockerはTLSとクライアント証明書を使用して、リモートDockerクライアントとデーモン間の接続を保護します。
ただし、これはまだ管理する必要がありますが、本格的なCAを通過する必要はありません。マシンが使用するすべての証明書を管理する社内CAにすることができます。