web-dev-qa-db-ja.com

侵害されたルートCAがSSL証明書を偽装する可能性はありますか？

私の質問は、httpsに対するMITM攻撃と、それらがエンドユーザーにどのように表示されるかについてです。

信頼されたルートCAが侵害され、不正なSSL証明書の作成を強制されたとします。特にMITMタイプの攻撃について、そのような証明書は何を達成できるでしょうか？

たとえばFacebookの場合、そこに行くと、（1）南京錠、（2）DigiCertによって署名された証明書、（3）SHAフィンガープリントが値81と一致することを確認できます。 AB：etc。

私の想定では、DigiCertが侵害されたCAである場合、1、2、3に一致する偽の証明書が生成される可能性がありますが、それは正しいですか？ SSLセキュリティモデルには、偽の証明書をFacebookに実際に発行された実際のSSL証明書と区別できるものは他にありますか？または、この証明書に基づいてMITMタイプの攻撃を検出できるものはありますか？

2番目の仮定は、DigiCert以外のCAが侵害されたCAである場合、偽の証明書が生成される可能性があるが、「DigiCert」とは表示されず、SHA key？それは正しいですか、それとも（技術的な観点から）ルートCAが別のルートCAになりすます証明書を作成することは可能ですか？そうであれば、それを検出する他の方法はありますか？接続はこの偽の証明書で暗号化されましたか？別のCAが明らかに同じSHAキーを持つ証明書を作成できますか？

この質問は、英国に近づく「スヌーパーズ憲章」に触発されており、デジタル通信をスパイする多くの権限を当局に与える予定です。重要なのは、「ブラックボックス」を使用してディープパケットインスペクションを実行し、プロバイダー（Facebookなど）が女王陛下の政府と共有することを選択しない可能性のある情報を収集するという話があったためです。私の推測では、そのような手法は不可能だと思います（確かにDPIでは望んでいません！）が、偽の証明書とMITM攻撃の可能性は私にはあまり明確ではありません。技術に精通したクライアントが偽の証明書を検出できると仮定した場合にのみ、政治的な理由でそれが試みられることはないと思います。

encryptiontlsman-in-the-middle
2
daveonhols

そのような妥協はすでに起こりました DigiNotar はほんの一例です。実際、攻撃者はほとんどすべての証明書をこの方法で偽装することができます。これは、ほとんどの証明書では、だれが署名したかは重要ではなく、ブラウザが信頼するCAによって署名されたことだけが重要だからです。

より安全な例外はほとんどありません。

  • ChromeとFirefox（およびIE EMETを使用？）には、ブラウザ/ OSでハードコードされた（ ピン留め ）いくつかの非常に重要なサイトの公開鍵のフィンガープリントがあります。この場合、偽の証明書が検出されます。DigiNotarの場合は 行われていたように です。
  • [〜＃〜] hpkp [〜＃〜] を使用すると、ブラウザーにこれらのキーが事前にピン留めされて出荷されていなくても、サイトは最初の使用時にブラウザーにピン留めするためのキーを提供できます。
  • 拡張検証証明書（EV）は、ブラウザにハードコーディングされている特定のCAのみが発行できます。

もちろん、理論的には、指紋を比較することにより、このような誤って発行された証明書を検出することができます。以前にアクセスしたサイトの証明書が変更されたかどうかをユーザーに通知する Certificate Patrol のような拡張機能がありますが、変更が正しいかどうか、またはこれが攻撃。 Perspectives のような拡張機能は、証明書を他のユーザーに表示される証明書と比較することにより、このプロセスを簡略化しようとします。しかし、これらの機能のいずれも現在ブラウザに同梱されていません。

この証明書の再作成は、SSLインターセプトファイアウォールで合法的に行われることが多いことに注意してください。ファイアウォールは、攻撃を検出するために復号化されたコンテンツにアクセスする必要があります。ただし、この場合、新しいルートCAは信頼できるものとしてブラウザーに明示的に追加されます。 OS /ブラウザに同梱されていないこれらのCAの場合、HPKPと事前ピン留めは通常、ブラウザによって無視されます。

8
Steffen Ullrich

ルートCAの侵害は、その信頼されたルートによって署名されたすべての証明書が実際に侵害されているという意味ではありません。むしろ、中間者攻撃に対して不正な証明書を作成して署名し、ブラウザーで信頼されているように見せることができることを意味します。

証明書署名要求（CSR）を認証局（CA）に送信すると、実際には公開鍵に署名しています。これは、IDを証明するためにCAが必要とする他のプロトコルとともに、ドメインの所有権を検証したことを示しています。あなたはあなたの秘密鍵を送信しないので、あなたの秘密鍵は秘密のままであるので、これは彼らがあなたのトラフィックを解読することができるようにすることを彼らに許可しません。

ルートCAを危険にさらすことは非常に困難です。ブラウザから信頼されるためには、セキュリティに関する厳しい要件があります。これには "key ceremony" が含まれます。これは、ルートキーを使用してあらゆるものに署名することを非常に面倒で法律に基づく操作に効果的にレンダリングします。これが、ほとんどのCAがルートから直接ではなく中間で署名する理由です。

誰かがDigiCertの中間署名鍵を侵害し​​たとしましょう。彼らは必要なすべての証明書を発行できます。ただし、これらのドメインのDNSはまだ制御されません。ただし、たとえば、企業またはホームルーターのDNSをハッキングして、ブラウザーに警告を表示せずに、Facebookなどの中間者攻撃を実行することもできます。この攻撃では、DNSハッキングされたWebサイトを使用して、トラフィックを傍受できるFacebookへのプロキシになります。

これは、SSLインターセプトを備えた企業ファイアウォールによって大規模に行われます（SSL証明書を、すべてのワークステーションによって信頼されている独自のSSL証明書に置き換え、適切な証明書で再暗号化して外部に送信します）。もちろん、中国のようにすべてのコンピューターからCAを信頼して、このようなSSLミドルマン攻撃を行う必要がある国でも行われています。

新しく生成された証明書は、前のキーのSHAフィンガープリントと一致しません。SHAでハッシュされたファイルまたは文字列の小さな違いは、別のバージョンと大きく異なるため、ハッシュでは "avalanche effect" と呼ばれていますが、これはブラウザの信頼には関係ありません。人々は常に証明書を置き換えており、ブラウザはハッシュの残りの定数をチェックしません代わりに、CRL（証明書失効リスト）またはより新しいOCSP（オンライン証明書ステータスプロトコル）を使用してCAにクエリを発行し、証明書が取り消されたか、または侵害されたかどうかを確認します。これは、侵害された証明書に対する2番目の防御層です。鎖。

ただし、OCSP/CRLの外部では、侵害された可能性のある証明書チェーンを検出できるのはユーザーの監視のみです。これが、信頼モデルのCAチェーンの代わりにDNSSECのように広く実装されるようになるのが長い間考えられてきた理由です。

3
Herringbone Cat