web-dev-qa-db-ja.com

「Firefox Hello」はどの程度安全ですか？

新しい「Firefox Hello」機能は、簡単で安全なビデオ会話を約束します。アカウントを作成する必要はありません。リンクをパートナーと共有して会話を開始するだけです。 このサイト では、通信は「プライベートで安全」であることが約束されていますが、実際に使用されている手法については詳しく説明していません。 webRTC のホームページも、よくある質問と同様に、あまり有益ではありません。

Firefox Helloはどの程度安全ですか？エンドツーエンドの暗号化を使用していますか？サーバーにメタデータを保存しますか？法執行機関から要求された場合、Mozillaは私の通信を解読できますか？

encryptionfirefoxpluginswebrtc
16
dervonnebenaan

最初にここに、WebRTCを説明するときに使用されるすべての略語の小さなリストがあります。そのため、わからない場合は、そこで見ることができます： https://hacks.mozilla.org/2013/07/webrtc- and-the-ocean-of-acronyms /

概要

ここに小さな要約があります。以下の詳細情報。

  • 接続はエンドツーエンドで暗号化されています
  • 暗号化にはDTLSおよびSRTPが使用されます
  • 可能な場合は、ピアツーピア接続が使用されます
    • 不可能である場合、トラフィックはTURNサーバーを介してルーティングされる可能性があります
  • シグナリングサーバーは、メタデータの交換に使用されます
    • 接続の暗号化に使用される証明書のハッシュも交換されるため、シグナリングサーバーが接続に対して中間者攻撃を実行することが可能になります。
  • STUNサーバーは、両方の会話パートナーが使用するIPアドレスのリストを取得するために使用されます
    • これはユーザーの追跡に悪用される可能性がありますが、これはセキュリティの問題よりもプライバシーの問題です。

安全保障

WebRTCは複雑なテクノロジーですが、注意すべきことがいくつかあります。

最初のリファレンス実装はオープンソースであり、Firefoxでの実装もそうです。ただし、それはテクノロジーそのものではありません。さらに、接続はエンドツーエンドで暗号化されます。非暗号化モードは 明示的に禁止 です。暗号化された接続の場合 [〜＃〜] dtls [〜＃〜] （UDPのTLSの変形）が使用されます（p。18 [〜＃〜] pdf [〜＃ 〜] ）およびオーディオおよびビデオ（メディア）通信はSRTPで暗号化されます（p。6、 [〜＃〜] pdf [〜＃〜] ）、 the DTLSハンドシェイクに使用されたものと同じキー （ DTLS-SRTP と呼ばれます）。データチャネルの場合、仕様には SCTP over DTLS が必要です。 DTLS-SRTP接続で使用される「キーマテリアル」へのJavascriptアクセスは許可されていません。したがって、これはブラウザで安全に処理されます。

Firefox 38以降 FirefoxはForward Secrecyスイートのみをサポートします。仕様では、Forward Secrecy暗号スイートを非Forward-Secrecy暗号スイートよりも優先することをお勧めします-そしてすべての実装はそれらをサポートする必要があります（p。19、 [〜＃〜] pdf [〜＃〜] ）。さらに 追加 使用できる暗号スイートに関する情報：

すべての実装は、暗号スイートTLS_DHE_RSA_WITH_AES_128_GCM_SHA256とTLS_DHE_RSA_WITH_AES_128_CBC_SHAおよびDTLS-SRTP保護プロファイルSRTP_AES128_CM_HMAC_SHA1_80を使用して、DTLS 1.2とDTLS 1.0の両方を実装する必要があります。

さらに、「ユーザーがメディアのセキュリティ特性を決定できるようにするインスペクターインターフェイス」が必要です。しかし現在、これはFirefoxに実装されていないようです。 about:webrtcにアクセスすると、WebRTCに関する詳細を表示できますが、これは、接続のセキュリティをチェックするためではなく、デバッグのために使用される可能性があることを示しています。

ルーティング

常にピアツーピア接続を確立しようとします。これを行うには [〜＃〜] stun [〜＃〜] サーバーが使用され、サーバーに接続しているユーザーのパブリックIPを返します。これは、簡単に言って、ファイアウォールとNATを回避するために複数の方法を試みて通信パートナーへの直接接続を作成するICEに使用されます。
WebRTC Stun
CC-BY-SA の下でライセンスされた画像 Mozilla Hacks

これがうまくいかない場合、プロセスはフォールバックして使用する [〜＃〜] turn [〜＃〜] を使用し、サーバーを介してトラフィックをプロキシします。

真ん中の男

基本的に、暗号化に使用される証明書はシグナリングチャネルを介して交換されるため、不正なシグナリングサーバーが接続をMITMできます。ただし、いわゆるIDプロバイダーを使用して相互のユーザー接続のIDを確認する場合、ユーザーはサーバーでMITM攻撃が行われていないことを確認できます。 Firefox Helloは、ログインにFirefoxアカウントを使用する機能を提供しますが、私が現在確認しているように、ID検証は行われていないため、現在、Mozillaが使用するシグナリングサーバーを信頼する必要があります。

シグナリングサーバーへの接続は、通常のHTTPS接続として保護されます（ただし、これは一般的にWebRTCには必要ありません）。

詳細： WebRTCでMITMを実行するにはどうすればよいですか？

プライバシー

@schroederによる 言及 の問題は、セキュリティではなくプライバシーの問題です。さらに、それは一種の望ましくないが、ユーザーのローカルIPアドレスをリークする不可避の影響です。 VPNと組み合わせた不適切な構成では、実際の外部IPが漏洩することさえあります。ただし、プライバシーへの影響かどうかは ディスカッション可能 です。

そして、それを使用したくない場合は、使用できます。 Firefox 42では、アドオンがWebRTC接続の一部を妨害および無効化できるようにする機能 実装されました 。 Firefox 42がリリースされる前に、about:configを使用して無効にすることができました（まだ使用できます）。さらに thereareaddons はWebRTCを無効にします。

その他のリソース： 現在の草案におけるIETFによるセキュリティの考慮事項

詳細に行きたいですか？ここに詳細情報があります： https://webrtc-security.github.io/

10
rugk

WebRTC はP2Pテクノロジーで、エンドツーエンドで default によって暗号化を実行します。

Mozillaのサーバーにはメタデータはありません。セッションごとの暗号化。Mozillaは復号化できません。

テクノロジーにはいくつかの脆弱性がある可能性があります（つまり、 ある ）。ただし、設計はアーキテクチャレベルでの質問に対処するものと想定されています。

10
schroeder