§ 4.6  Module 4 — The Browser Gets a Dial Tone

Securing the Call: How DTLS-SRTP Won

SSL added and removed here! ☺— NSA "Google Cloud Exploitation" slide, disclosed by the Washington Post, October 2013

4.6.1A key in every mailbox: what SDES actually did

To see why SDES lost, look at what it put on the wire. An SDES-secured offer carries a line like this in each media section:

a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:PS1uQCVeeCFCanVmcjkpPywjNWhcYD0mXXtxaVBR|2^20|1:32

Listing 4.6.1 — an SDES a=crypto attribute (RFC 4568). The inline: parameter is the SRTP master key and salt — thirty octets, base64-encoded, in plaintext SDP.

That is not a hash, not a reference, not a wrapped secret: it is the key. Whoever reads this SDP can decrypt every SRTP packet of the session, and SDP is precisely the thing that signaling exists to carry. In a SIP deployment the offer transits your outbound proxy, perhaps a session border controller, perhaps several intermediate proxies, each of which terminates and re-originates the transport. "Just encrypt the signaling" does not help: SIP-over-TLS is hop-by-hop — each proxy decrypts, processes, and re-encrypts, so every hop holds the plaintext SDP and therefore the media key. The same is true of any WebRTC-style signaling service: the WebSocket server that relays your offers holds them in memory, likely logs them, and possibly backs the logs up.

The consequence is the one that mattered after 2013: compromise becomes passive and retroactive. An attacker — or a subpoena — that obtains the signaling logs plus a capture of the encrypted media can decrypt calls that ended months earlier, without ever having touched the media path while the call was live. Nobody had to target you; the keys were sitting in an archive, waiting. This is the precise property the MUSCULAR program exploited against inter-datacenter links, and it is why "the signaling server can read the key" went from a documented trade-off to an unacceptable design in a single news cycle.

4.6.2Moving key agreement onto the media path

DTLS-SRTP's answer is architectural, not cryptographic cleverness: run the key agreement over the same path the media takes, so the signaling plane never sees key material at all. The vehicle is DTLS — Datagram TLS, designed by Nagendra Modadugu and Eric Rescorla at Stanford (NDSS 2004), standardized as DTLS 1.0 in RFC 4347 (April 2006) and DTLS 1.2 in RFC 6347 (January 2012). DTLS is TLS re-plumbed for unreliable transport: it adds explicit sequence numbers, retransmission timers for handshake flights, and tolerance for reordered records, so a full TLS handshake can complete over UDP — which, after Module 3, you know is the only transport the media path realistically has.

Each RTCPeerConnection generates its own certificate when it is constructed — self-signed, ephemeral, telling you nothing about who the peer is. Chrome 52 (July 2016) switched the default from RSA-1024 to ECDSA P-256, cutting handshake CPU cost; the static RTCPeerConnection.generateCertificate() method lets an application pre-generate and persist one. Self-signed is the point, not a shortcut: there is no certificate authority that could meaningfully vouch for "this browser tab," so DTLS-SRTP does not even try. Authenticity is established by a different anchor, which is the subject of the next section.

The handshake itself runs over the candidate pair that ICE selected — the same five-tuple that will carry media moments later. That means three protocols share one UDP flow: STUN connectivity checks keep running, DTLS records carry the handshake (and later the SCTP data channels), and SRTP packets carry the media. The receiver demultiplexes by the first byte of each packet: 0–3 is STUN, 20–63 is DTLS, 128–191 is RTP or RTCP (RFC 7983). One port, one NAT binding, three protocols — a design forced by everything Module 3 taught about how expensive each additional NAT traversal is.

4.6.3The fingerprint and the setup roles

If the certificates are self-signed, what stops anyone from presenting any certificate? The answer is two SDP attributes that every WebRTC offer and answer you have generated since § 4.3 has carried, and that you can now finally read:

m=audio 9 UDP/TLS/RTP/SAVPF 111
c=IN IP4 0.0.0.0
a=ice-ufrag:F7gI
a=ice-pwd:x9cml/YzichV2+XlhiMu8g
a=fingerprint:sha-256 7A:3E:91:0C:55:F2:88:1D:4B:C0:26:E9:73:AF:5A:10:8E:64:D2:39:BB:07:C5:E1:42:9F:6D:18:A4:50:CE:2B
a=setup:actpass

Listing 4.6.2 — the security attributes of a WebRTC media section. Even the m= line's transport token, UDP/TLS/RTP/SAVPF, names the stack: DTLS under secure RTP with feedback.

a=fingerprint (RFC 8122, March 2017 — Lennox and Holmberg, refining Lennox's RFC 4572 of July 2006) is a cryptographic hash — in practice SHA-256 — of the peer's DER-encoded certificate, printed as colon-separated uppercase hex. During the DTLS handshake, each side hashes the certificate the other actually presented and compares it against the fingerprint received in signaling. Match: the entity you are doing cryptography with is the entity that authored the SDP. Mismatch: the handshake is aborted and the transport fails — there is no prompt, no "proceed anyway," no unencrypted fallback. The fingerprint is the trust anchor of the entire call, and it is the only security-relevant thing the signaling plane carries.

a=setup settles who plays TLS client. The attribute predates WebRTC by years — RFC 4145 (September 2005, Yon and Camarillo) invented it for TCP media streams — and RFC 5763 §5 pins its use for DTLS-SRTP within offer/answer: the offerer must send a=setup:actpass ("either role; you choose"), and the answerer replies with active (it will initiate the handshake, acting as TLS client) or passive (it will listen, as server). Answerers almost universally choose active, for a latency reason worth remembering: the answerer can fire its ClientHello the instant its ICE checks succeed, without waiting for any further signaling round trip. Note the independence of roles here — the offerer is usually the ICE controlling agent, yet its counterpart is usually the DTLS initiator. The two state machines share a packet flow and nothing else.

Test yourself before moving on — the two questions below are answerable from this section alone.

4.6.4From handshake to SRTP keys: RFC 5764

A subtlety that separates DTLS-SRTP from "media over DTLS": after the handshake completes, the media does not flow as DTLS application data. DTLS records would add per-packet overhead and hide the RTP header from the transport machinery (header extensions, RTCP feedback — Module 6 depends on reading those). Instead, RFC 5764 defines a TLS extension, use_srtp, sent in the ClientHello, through which the peers negotiate an SRTP protection profile; and once the handshake completes, both sides run the TLS keying-material exporter (RFC 5705, March 2010, Rescorla) with the fixed label EXTRACTOR-dtls_srtp to derive the SRTP master keys and salts from the DTLS master secret. Client-write and server-write keys fall out of one exporter call; the DTLS association itself stays up, carrying only handshake maintenance and SCTP data-channel traffic, while the audio and video ride SRTP with the exported keys.

Two families of profile matter in practice. The RFC 5764 originals are counter-mode AES with an HMAC tag — SRTP_AES128_CM_HMAC_SHA1_80 encrypts with AES-128-CM and authenticates with an 80-bit slice of HMAC-SHA1, two passes over every packet. RFC 7714 (December 2015, McGrew and Igoe) added the AEAD profiles SRTP_AEAD_AES_128_GCM and SRTP_AEAD_AES_256_GCM, which encrypt and authenticate in a single AES-GCM pass with a 16-octet tag — cheaper per packet on modern hardware with AES instructions, and structurally immune to the class of bugs where encryption and authentication disagree about what was processed. Browsers negotiate GCM when both ends offer it; you can see what won on any live connection through getStats:

const stats = await pc.getStats();
let transport;
stats.forEach((s) => {
  if (s.type === 'transport' && s.dtlsState === 'connected') transport = s;
});
console.log(transport.dtlsCipher);    // e.g. "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256"
console.log(transport.srtpCipher);    // e.g. "AES_CM_128_HMAC_SHA1_80"
console.log(transport.tlsVersion);    // "FEFD" — the wire bytes of DTLS 1.2

const localCert  = stats.get(transport.localCertificateId);
const remoteCert = stats.get(transport.remoteCertificateId);
console.log(remoteCert.fingerprintAlgorithm, remoteCert.fingerprint);
// ^ must equal the peer's a=fingerprint line — you will assert exactly this in Problem 1

Listing 4.6.3 — the transport→certificate walk. This is a recipe to reuse, not the full stats model; the complete stats graph is the subject of § 6.4.

The transport stats entry is the DTLS association's dashboard — dtlsState, negotiated ciphers, TLS version — and its localCertificateId/remoteCertificateId fields point at certificate entries carrying each end's fingerprint. Those fields close the loop on this lesson's central claim: the certificate that the DTLS handshake actually verified is observable from JavaScript, and it must equal the fingerprint that traveled through your signaling channel. Problem 1 has you verify that chain on a live connection — and then break it.

4.6.5The threat model: what a bad signaling server buys

RFC 8826 and RFC 8827 (both Rescorla, January 2021) write down WebRTC's threat model with unusual candor, and its central assumption deserves to be stated plainly: the signaling server is not trusted with media confidentiality. Work through what a fully compromised signaling service can and cannot do, because Problem 2 will grade you on exactly this ledger.

It can read everything in the SDP: your codecs, your ICE candidates and therefore your network addresses, your certificate fingerprints, and — inescapably — the metadata of who called whom, when, for how long. It can refuse to relay your offer, silently failing any call it dislikes. It can rewrite the SDP in flight, and this is the one capability with teeth: replace the a=fingerprint in each direction with the fingerprint of its own certificate, place itself on the media path, and terminate two separate DTLS-SRTP associations — a full man-in-the-middle, with both hops genuinely encrypted, just each to the attacker. What it cannot do is the SDES failure mode: passively decrypt media, live or recorded. The SRTP keys are born in the DTLS handshake on the media path and exported locally at each end; no quantity of logged SDP contains them. A TURN relay, likewise, forwards SRTP ciphertext and never holds keys — relayed calls are exactly as confidential as direct ones.

The fingerprint-substitution attack is real but expensive for the attacker: it is active, it must persist on the media path for the call's entire life, and it leaves evidence — each endpoint now holds a remote certificate whose hash matches nothing the far end ever generated. Any comparison of fingerprints over a channel the signaling server does not control exposes it, which is ZRTP's spoken-string idea reborn. RFC 8827 §7 standardized a browser-level version: an identity provider (IdP) framework in which a third party — one you actually trust — signs your fingerprint, delivered via a=identity in the SDP and the peerIdentity API. It is the most carefully designed dead letter in WebRTC: Firefox implemented it, Chrome never did, no major service deployed it, and the ecosystem answered the problem at the application layer instead — apps that need MITM resistance against their own servers verify keys out of band or run end-to-end encryption above the transport, as Module 7 will show.

One more property is unique among the web's media technologies: WebRTC encryption has no off switch. There is no API to request plain RTP, no null cipher for media, no RTP/AVP answer a browser will accept; createOffer() emits a fingerprint whether you like it or not. This was a deliberate 2011-era decision, informed by the SIP world's experience, where "SRTP optional" had meant, in deployment after deployment, "SRTP off." Mandatory encryption removed the downgrade attack by removing the thing to downgrade to.

Problems for § 4.6Check your understanding

First, verify the fingerprint trust chain on a real connection — and confirm that breaking it kills the transport; then account precisely for what a compromised signaling server can and cannot do.

¶Field quirks

What the specifications say, and what the browsers actually do, are two different documents. These are the divergences that cost production teams their weekends.