DTLS-SRTP
Also written a=fingerprint, a=setup:actpass, use_srtp
How WebRTC keys its media: a DTLS handshake over the ICE-selected path, whose exported keys feed SRTP. There is no unencrypted mode.
Once ICE has picked a candidate pair, the two ends run a DTLS handshake over that same 5-tuple. The handshake negotiates a use_srtp extension, and the keying material it exports becomes the SRTP keys that protect the actual media. STUN, DTLS and SRTP all share the port and are demultiplexed by looking at the first byte.
The certificates are self-signed and prove nothing on their own. What ties them to the right peer is a=fingerprint in the SDP: each side publishes a hash of its certificate through signalling, and rejects the handshake if the presented certificate does not match. Your media encryption is therefore exactly as trustworthy as your signalling channel.
a=setup:actpass in the offer lets the answerer choose which side plays DTLS client. With BUNDLE there is one handshake for the whole session, not one per media section.
Note what this does not give you. A forwarding server terminates DTLS, so it holds the keys and can read everything passing through it. End-to-end encryption needs a second layer on top.
Specs
See also
Read more
- WebRTC DTLS handshake failed: how to find out whyICE says connected, then connectionState goes to failed. That is the DTLS handshake, and RTCDtlsTransport's error event names the exact cause.
- WebRTC E2EE with SFrame: what your SFU can still readSFrame hides WebRTC media from the SFU, not the metadata. Your server still sees who spoke, when and how loudly, from the audio level header extension.