web-dev-qa-db-ja.com

WebRTCのセキュリティと暗号化

私はWebRTCアプリケーションを構築していて、セキュリティについて本当に心配しています。

私はこの非常に興味深い記事を読みました： https://webrtc-security.github.io

私はネットワーキングセキュリティの専門家とはほど遠いので、正しく機能していること、およびどのような点について心配する必要があるかを確認したいだけです。

  1. 原点

    • WebRTC「ルーム」は、HTTPS（LetsEncrypt）を介してWebサイトでホストされています。
    • JavaScript APIに、可能な限りECDSA証明書を生成するように強制します（ただし、これらの証明書の役割を正確に認識していませんか？！）

  2. シグナリング

    • WSSを介してアクセス可能なWebSocketシグナリングサーバーを構築しました。
    • このシグナリングサーバーは、SDPオファー、回答、ICE候補の転送を実際に許可する前に、有効なRFC7519 JsonWebToken（発行元と有効期限を確認）を含む「認証」特別メッセージを受信する必要があります。すべてのJWTは4096ビットの秘密鍵で暗号化されています。
    • 認証されると、WebSocketサーバーは切断されるまで接続を認証済みと見なすため、このJWTは不要になります。

  3. ネットワーキング

    • TLSを使用してTURNサーバー（resiprocate-turn-server）もセットアップしました。STUNおよびTURNSプロトコルからアクセスできます。

stun:stun.my-domain.org:3478

turns:turn.my-domain.org:5349（有効なユーザー名とパスワードが必要）

  • このSTUNサーバーへのアクセスを一部のドメイン起源に制限する必要がありますか？

Web開発者として、ある種のMITM攻撃（実際にはどのような種類の攻撃か）について心配する必要がありますか？

tlsnetworkp2pwebrtc
4
Flo Schild

これは実際には本当に良い質問です。私の答えは100％確実ではありません...ですから、私が知っていること、疑わしいこと、およびそれをテストする方法について説明します。

まず、WSSを使用している場合は、サーバー側で問題ありません。 WS over WSSの使用は、HTTPS over HTTPの使用と実質的に同じです。

ここで注意が必要な部分...クライアントAとBの両方がWSSでサーバーCに接続していて、次にSTUN＆TURNSを使用する場合、AがそれぞれのWSS接続と同じWSS接続でBに接続するのではないかと思います。以前はサーバーCとの接続に使用されていました。キーワードが疑わしいです

私はhttps対応のSTUN＆TURNSサーバーをテスト用にすぐに利用できないので、個人的にテストすることはできません。ただし、クライアントAとBにWiresharkを配置すると、クライアント間のトラフィックを監視できるはずです。また、クリアテキストを使用して回線に到達しない場合は、暗号化は維持されます。

2
CaffeineAddiction