概要
WebRTC についてググると、簡単な tutorial や NAT を越える仕組みについての簡単な説明などは沢山出てくるのですが、セキュリティについての話はそんなには出てきません。
End to end で暗号化されているの？ 暗号化の仕組みは？ どうやって相手を認証するの？ というような基本的なことの説明もすぐには発見できませんでした。
なので、調べたことをちょろっとまとめておくことにしました。
ちなみに、identity providers (IdP) による認証の話は扱いません。
End to end での暗号化と認証
結論から言うと、WebRTC では end to end で暗号化されています。TURN server を経由する場合でも同様です。
暗号化の仕組みですが、WebRTC の通信を始める際、各 peer は self-signed certificate を作成します。
参考: certificate を作成するタイミングは、RTCPeerConnection が作成される時です。
self-signed certificate（自己証明書）とは
「信頼できる認証局からの認証がない、公開鍵認証用の証明書」です。認証局から認証されていなくても、暗号化通信はできます。認証局は「その証明書を持っているのが誰か」ということを保証してくれます。認証されていないということは、「相手と暗号化通信をしているけれども、相手が誰なのか（自分の意図している相手なのか）は分からない、ひょっとして悪い人かもしれない」ということです。
この certificate を使用して、end to end の暗号化通信(DTLS)を行います。やったね！
・・・とはいかず、これだけだと、暗号化通信はできているけれど、「通信相手が自分の意図した相手か」が分かりません。
これは、peer to peer の通信を始める前の、signaling 段階に仕込みを入れることで解決されます。
WebRTC の簡単な構成図を示します。
WebRTC において、signaling server はとても重要です。Peer to peer の通信を始めたいと思っても、通常、そもそも相手の IP アドレスすら分かりませんので、何かしら仲介する仕組みが必要になります。
例として、あなたが SNS を運用しているとして、そのサイトは signaling server の機能を持っているとしましょう。
あなたのサイトは Alice と Bob を id/pass などで認証しているとします。
今、Alice と Bob は互いに通信したいと考えたとします。Alice と Bob は、signaling server を通じて互いの情報(SDP) - 自分への接続先 IP アドレス（ICE）や使用可能 codec など - をやり取りします。その際に、先ほど作成した self-signed certificate の fingerprint もやり取りします。これにより、peer to peer の通信をする際に相手が提示してきた certificate と、signaling server 経由で受けとった certificate の fingerprint を突合することができます。つまり、Singling server が「今回の通信で Bob が使用する certificate はこれです」と教えてくれるので、その後に Bob（と思われる相手）と peer to peer の通信をする際、相手の提示してきた certificate が正しいかを確認することで、相手が Bob かどうかを判別することができます。
＃これまでの説明の通り、相手を認証するのには「Signaling server が信頼できる」ということが大前提になります。なので Signaling server は重要です。
参考: https://tools.ietf.org/html/rfc5763
The media is transported over a mutually authenticated DTLS session
where both sides have certificates. It is very important to note
that certificates are being used purely as a carrier for the public
keys of the peers. This is required because DTLS does not have a
mode for carrying bare keys, but it is purely an issue of formatting.
The certificates can be self-signed and completely self-generated.
All major TLS stacks have the capability to generate such
certificates on demand. However, third-party certificates MAY also
be used if the peers have them (thus reducing the need to trust
intermediaries). The certificate fingerprints are sent in SDP over
SIP as part of the offer/answer exchange.The fingerprint mechanism allows one side of the connection to verify
that the certificate presented in the DTLS handshake matches the
certificate used by the party in the signaling.