SSLの既存の認証局システムに代わるものは何ですか？
現在のCAシステムは多くの人々にとって非常にうまく機能しますが、個々のCAの手に多くの力を与え、CAハックを顧客やビジネスにとって破壊的なものにする可能性があります。認証局に代わるものはありますか？そのようなシステムに切り替える際の課題は何ですか？さまざまな分散型P2Pのようなシステムの提案を見てきましたが、これまで何も生まれていません。
「代替案」は、既存のブラウザで、将来的に機能する可能性のあるものと、現在機能するもののどちらが必要かによって異なります。
現在、Webブラウザーはサーバーが X.509証明書 を送信することを期待し、ルートCAのセットに対してそれらを検証しますブラウザ（またはオペレーティングシステム）に統合されています。つまり、追加のソフトウェアをインストールしなくても機能するものが必要な場合は、ルートCAのセットを変更するだけです（トラストアンカー）。あなたはできる：
- 一部のCAを削除します（ 言われているように 信頼できるすべてのCAが同じようにアクティブであるとは限らないため、ブラウジングエクスペリエンスに実際に影響を与えることなく、ほとんどを削除できます）。
- 新しいトラストアンカーを追加します。 トラストアンカーは「信頼できる名前と公開鍵アプリオリであることに注意してください。トラストアンカーは通常証明書としてエンコードされます（その形式はそのため便利です）、そして通常はは自己署名されます（ほとんどの場合、証明書には、空のままにできない「署名」）。ただし、自己署名されていない証明書は信頼できます。エンドエンティティ証明書を信頼することもできます（つまり、特定のSSLサーバーの特定の証明書を信頼します。これはdirect trustと呼ばれます）。直接信頼では、信頼できるものを非常に細かい単位で手動で管理します。直接信頼を使用すると、revocationの利点が失われることに注意してください（直接信頼された証明書は、手動での介入がない限り信頼できません。不信情報を自動的に伝播することです）。
（直接信頼モデルはSSHが従うものであり、うまく機能することに注意してくださいSSHの使用コンテキストで。）
将来的には、他のモデルが存在する可能性があります。いくつかの提案があり、一部は既存のソフトウェアアドオンによってサポートされています。私の知る限りでは、「一般的に使用可能な」レベルにはまだ達していません。たとえば、次のようなものがあります。
DNSSECおよびDANE ：DNSSECは、主にDNSによって返されるデータを認証するために、DNSシステム上の [〜＃〜] pki [〜＃〜] をマッピングすることですそれ自体ですが、SSLサーバーキーを配布するために活用できます（DANEについて）。これは依然として階層型PKIであり、トラストアンカーのセットが制限されています。ルートCAの既存のセットとの違いは、主にプレーヤーの変更です。新しいゲートキーパーのセットは小さくなり、既存のルートCAと部分的にしか重複しません。また、DNSSEC/DANEはWebサーバーを認証するプロセスをDNSインフラストラクチャとアクターにバインドしますが、これが良いか悪いかは明確ではありません。
A Web of Trust OpenPGPと同じように。 WoTモデルはグラフの超接続性に依存しています。事を簡単にするために、WoTでは、誰もがCAであり、各アクターは独自の一意のルートCAです。騙されやすいまたはまったくの悪意のある「CA」に対処するために、WoTユーザー（つまりWebブラウザー）は、多くのパス異なるCAを通過し、すべてがターゲットサーバーキーの配置に同意します。 WoTの分散型の性質は、政府や行政のように見えるものを不信にする人々の間で非常に人気があります。ただし、WoTのセキュリティはクリティカルマスに大きく依存しています。十分な数の人々が共同作業を行うまで、多くのセキュリティは得られません。実装については Monkeysphereプロジェクト を参照してください（ブラウザーのアドオンを使用）（ただし、プロジェクトの品質についてはあまり知りません）。
Convergence は Perspectivesプロジェクト の子孫です。それに慣れると、収束はHopeとLazinessに依存します。 Convergenceが想定していることは、長期間にわたって多くの人々の見解で、偽の証明書を使用して特定のサーバーを積極的に偽装することは、攻撃者が困難/高額/面倒であることに気付くことです。つまり、実用的な 中間者攻撃 は被害者（特定のWiFiホットスポットのユーザーなど）の近くにあります。この場合、影響を受けるのはごく少数の人か、サーバーの近くです。これには、かなり目立つため、長続きしない、大規模なもの（重いDNSポイズニングなど）が必要です。このモデルでは、収束は最小限の集中化であり、比較的安価な素晴らしいソリューションです（公証が必要であり、de facto集中化が期待できますが、ルートCAの現在のセットほど完全ではありません）。 。
重要な点は、現在のシステムが「機能する」ことです。PKIを標的とする実際の攻撃は非常にまれです（広く知られていますが、まだまれです）。ルートCAを備えた実際のシステムは、攻撃者が他の方法（主に人間のユーザーの信憑性を悪用している方法）を介して迂回する方が簡単であることに気づくのに十分なほど困難です。そのため、せいぜい同じことを行う別のシステムに置き換えるインセンティブはほとんどありません。したがって、代替案にはいくつかのメリットがありますが（大部分は財政的および政治的観点から）、私たちが知っている「Web」のために、近い将来に既存のルートCAを削除する可能性は比較的低いと思います。
閉じたアーキテクチャで、Webではなく、クライアントとサーバーの両方を制御する場合は、必要なシステムを使用できますが、閉じたアーキテクチャはまさに階層型PKIが非常にうまく機能する状況。
1つの代替案は DANE/TLSA です。これは、DNSで自己署名鍵を許可するRFC標準です。
課題の1つは、これが非常に新しく、ほとんどのクライアントソフトウェアがまだサポートしていないことです。 （Chromeが新たに追加されます）さらに、DNSは、特にWiFiネットワークなどで、さまざまな攻撃を受けます。
DNS攻撃を修正する1つの方法は、DNSSecを使用し、クライアントソフトウェアがDNSSecを提供するドメインにのみDNSSecを使用するようにすることです。この後者の機能が存在しない場合、ユーザーはSSLストリップタイプの脆弱性にさらされることになります。
SSLは Secure Remote Password（SRP） もサポートしています。これは、証明書の代わりにパスワードを使用して認証する場所です。あまりにも悪いブラウザはそれをサポートしていません。
収束 もあります。これは、CA/PKIシステムの代替品です。理論的には、自己署名証明書を使用しても、MITM攻撃から身を守ることができます。また、不正なCAに対する保護も提供します。
現在のPKIと同じ規模で実装されている場合、信頼チェーンの概念自体は、信頼Web、共有シークレット、またはその他のメカニズムよりも多少脆弱ではないことを指摘する価値があります。
主な問題は、信頼できるCAの急増、および信頼を目的としたCA間の区別の欠如です。アプリケーション固有のユースケース（つまりWebブラウザーではない）の場合、これを回避して、非常に堅固で信頼できるプライベートPKIを作成できます。 SSL/TLS実装では独自の信頼ルートを指定できるため、MozillaおよびMicrosoftが提供する人気のあるCAリストを含める必要がある理由はありません。実際、ブラウザを使用していない場合、それからあなたがすべきである理由はほとんどありませんあなたがすべきでない多くの理由を含めます（== --- ==）。あなたが唯一のCAである場合、攻撃面は大幅に制限されます（Microsoftが最近学んだように）。
ブラウザのPKIの場合、より理想的なソリューションは、信頼カテゴリ（例：*.bank金融機関など）、そして最も重要なのはCA権限を特定のTLDのみに制限するです。これにより、香港の郵便局はPaypalまたはGoogleに署名できなくなります。
しかし、現在のテクノロジーは一般的な使用によって効果的に固定されているため、これまたは他の代替セキュリティインフラストラクチャが主流になる可能性は効果的です）ゼロ