Convergence（CAの代替）は、公証人がMITM化されるのをどのように防ぐのですか？
私は Convergence とそれがどのように機能するかを調査してきましたが、ターゲットシステムの近くで発生するMITM攻撃に対してどのように効果があるのか理解できません。私の理解では、Convergenceは、多数の公証サーバーに、宛先サーバーから同じSSL証明書が表示されることを確認するよう要求することで機能します。ただし、攻撃者は宛先サーバーのすべてのトラフィックが最初に攻撃者のサーバーを通過するように攻撃を設定することはできませんか？私はそれがどのように実行可能かわかりませんが、CAから偽造された証明書を取得するよりも複雑になりますか（DigiNotarは冗談はさておき）？
これは、宛先証明書をローカルでキャッシュしていないユーザーにのみ影響することを知っているので、おそらくこれは問題にはなりません。それでも、それは理想的とは言えないようです。 Convergenceが問題の解決策であるか、それとも単なる別の種類の問題であるかを理解しようとするだけです。
収束の詳細は Perspectives Project 、特に対応する senixの記事 にあります。
すべての公証人からサーバーを「隠す」ことができる攻撃者（つまり、サーバーのローカルネットワークを介して攻撃する攻撃者）は、作成者がLと呼ぶものですサーバモデル。最終的には、この攻撃は「ネットワークパースペクティブ」を使用するデフォルトの公証で動作します。つまり、公証人は攻撃者の証明書を「サーバーの新しい証明書」であると見なし、これは有効です。ただし、攻撃者がアクティブな攻撃を停止するとすぐに、古い証明書が再び表示されるようになり、公証人に警告フラグが表示されます。証明書の更新は確かに有効であり、古い証明書の再出現は、不正行為を示唆しています。
ただし、公証人がCAベースの検証を含む他の検証戦略を使用することを妨げるものは何もありません。
そのシステムには2つの主要なアイデアがあります。
単一の信頼ポイントを回避するために、複数のコンセンサスクォーラムを使用して、検証を外部サーバー（公証人）に委任します。この種類の委任は、X.509獣医のコンテキストで、名前 [〜＃〜] scvp [〜＃〜] で既に存在します（ただし、収束プロトコルは非常に単純です）。
公証人にセキュリティを向上させるためにメモリを使用してもらいます。通常のSCVPサーバーがコンテキストフリーの検証（真のX.509の方法）に依存するのは少し短い時間のキャッシュであり、CPUコストを節約するためだけである場合、収束の公証人は主に一時的な安定性に依存しています。証明書は通常、特定のサーバーの1年または数年は変更されません。したがって、SSLサーバー証明書が以前と同じであることを簡単に確認できます。 X.509とSCVPは、5分ごとに新しい証明書を取得するサーバーを処理できます。これは素晴らしいですが、実際にはまったく役に立ちません。
コンバージェンスの推論の要点は、攻撃者が公証人によって実行されたチェックを正常に無効にすることができれば、従来のCAと通信するときにサーバーを偽装することもできるため、従来のCAモデルを無効にすることもできます。したがって、セキュリティに関しては、収束は現在の状況よりも悪くはありません。 X.509の方がはるかに優れていることに注意してください。特に、revocationは実際にはConvergenceでサポートされていません。既存のクライアントはとにかく失効をチェックしない傾向があるため、Convergenceは従来のCAよりも悪くありません。
つまり、コンバージェンスはSSLをより安全にすることではなく、全体的なセキュリティを低下させることなく既存のCAを削除することです。
Potentially、公証人は、通常のX.509パス検証を含め、希望する検証プロセスを実行できます（そして、提案する種類のMitMを回避します）。公証人はクライアントよりもはるかに少なく、それらの公証人はより「セキュリティ意識」があると予想できるので、将来のある時点で結論できる収束は実際にWebを改善するセキュリティ。ただし、Convergenceが広く使用されることによる最も直接的な影響は、権力のシフトです。ゲームマスターは、もはやMicrosoft（Internet Explorerでデフォルトで認識されるリストにどのCAを入れるかを決定する）ではなく、クライアントがデフォルトで使用する最高のネットワーク接続（おそらくGoogle）。
Convergenceプロジェクトは、カーネギーメロン大学による Perspectives Project に基づいています。 Perspectives Projectはこれについてもう少し情報があります。 （ 彼らの論文も参照 ）
攻撃者がターゲットシステムの近くに座っている場合、それは可能ですが、実行は非常に困難です。論文より：
Lserver + k・nmの侵害：この攻撃は、以前のLclient + k・nmシナリオよりも強力です。これは、宛先サービスのリンクを制御することにより、正当な公証人でさえ攻撃者のキーを監視するためです。その結果、侵害された公証人がqより少ない場合でも、クライアントは時間的な安全性に完全に依存しています。
「時間的安全性」は次のように定義されます。
代わりに、「一時的な安全性」の概念を使用します。つまり、クォーラム期間のしきい値が実際の攻撃期間よりも長い限り、クライアントは安全です。
紙はまたそれに言っています：
私たちのモデルでは、あらゆるネットワークまたは公証コンポーネントが危険にさらされることを許可していますが、アブラハムリンカーンから借りて、攻撃者が「すべての[コンポーネント]をいつでもだまし、一部の[コンポーネント]をいつでもだますことができると想定しますが、すべての[コンポーネント]を常にだますことはできません。」つまり、攻撃は次のいずれかであると想定します。（1）特定のネットワークスコープに限局するか、（2）期間が限定されています。これは、攻撃が大きいほど、検出および修正が容易になるためです。
そのため、クライアントと公証サーバーによってキーがキャッシュされていない場合、これは問題のようです（キーもキャッシュするため）。攻撃者が常にすべてのシステムをだますことができる場合、それは可能です。ただし、単一障害点がある現在よりも安全である必要があります。
これに対する私の理解は次のように機能します：
攻撃者がすべてのトラフィックをサーバー経由で転送している場合、はい、彼らは公証人へのトラフィックを停止する可能性があります。
クライアントには公証人の証明書のコピーがローカルに保存されているため、クライアントと公証人の間のトラフィックを変更できませんでした。公証人からの応答がクライアントが保存した証明書と一致しない場合、クライアントは応答を受け入れないはずです。 。
[編集]
現在、証明書が一貫して表示されていることを確認するためにGoogleのヘルプ（ Google証明書参照 ）を使用するConvergence公証サーバーのフォークがあります。