TURNを介したWebRTCトラフィックはエンドツーエンドで暗号化されますか？
WebRTCトラフィックはDTLSを使用して暗号化されます-わかりました。しかし、TURNサーバーを介して中継されるトラフィックについてはどうでしょうか。
トラフィックがtrulyエンドツーエンドで暗号化されていることを確認する信頼できるリソースを探しています（「エンドツーエンド」は時々いくつかのことを意味することがあるため）。つまり
- ピアとTURNサーバーの間には「エンドツーエンド」の暗号化があることに注意してください。
むしろ、
- ピア間でエンドツーエンドであること
- tURNサーバーで復号化/再暗号化されないようにする
- そして、TURNサーバーがシークレットにアクセスする方法がないこと
これに対する明確な答えを見つけることができませんでした。
見るべき場所はTURNが提案する標準 RFC 5766 です。この標準は、クライアントとピアの間でアプリケーションデータを含むUDPパケットを中継する手段を提供します。
割り当てが作成されると、クライアントはアプリケーションデータをサーバーに送信し、どのピアにデータを送信するかを示し、サーバーはこのデータを適切なピアに中継します。クライアントはTURNメッセージ内でアプリケーションデータをサーバーに送信します。サーバーでは、TURNメッセージからデータが抽出され、UDPデータグラムでピアに送信されます。逆方向では、ピアはアプリケーションデータをUDPデータグラムで中継割り当てトランスポートアドレスに送信して割り当てることができます。次に、サーバーはこのデータをTURNメッセージ内にカプセル化し、どのピアがデータを送信したかを示すとともにクライアントに送信します。
TURNが解析する最上位の層はUDP層です。アプリケーションデータレイヤー（あなたの場合はWebRTCプロトコル）を理解または変更しません。標準は言う：
データが変更または偽造されていないことを確認したいアプリケーションは、アプリケーションレベルでデータを整合性保護する必要があります。
これは、アプリケーションデータを整合性保護できることができ、TURNは変更なしでデータを中継することを意味します。また、アプリケーションデータをラップして転送するだけであることを示すTURNプロトコル（ここでは繰り返さない）の詳細も確認できます。
最後に、規格はこれを盗聴について述べています：
TURN over TLSを実行してもサーバーとピア間のアプリケーションデータは保護されないため、TURNによってリレーされるアプリケーションデータの機密性は、アプリケーションプロトコル自体によって提供されるのが最適です。アプリケーションデータの機密性が重要な場合、アプリケーションはデータを暗号化するか、保護する必要があります。たとえば、リアルタイムメディアの場合、SRTPを使用して機密性を提供できます。
この抜粋の推奨事項は、WebRTCが使用するDTLS-SRTPなどのプロトコルでアプリケーションデータを暗号化することにより、機密性を保護することです。
TURNはアプリケーションデータを解釈または変更しないため、TURNを使用しないと存在しないWebRTCアプリケーションデータトラフィックにセキュリティの脆弱性が追加されることはありません。 WebRTCデータはWebRTCエンドポイント間で暗号化されます。
現在、「TURNサーバーがシークレットにアクセスする方法がない」ことを誰も保証できません。不正なTURNサーバーは、ネットワークパケットを傍受できる他のユーザーと同じくらい簡単に、接続に対して中間者攻撃を試みる可能性があります。 TURNリレーを使用してもWebRTCのセキュリティが弱まることはありません。
DTLSが適切に実装および使用され、DTLSアルゴリズムと暗号が安全であると想定している限り、WebRTCトラフィックはエンドツーエンドで保護する必要があります。 SSLベースのスキームを使用するには、HTTPSと同様に、他のエンドポイントの証明書を検証する必要があります。また、HTTPSと同様に、これには事前に帯域外で証明書のIDを交換するか、信頼できるサードパーティを使用する必要があります。 HTTPSのように、証明書が適切に検証されない場合、（TURNサーバーだけでなく、だれでも）MITM攻撃を受ける可能性があります。