Overview
This series explains how deployed WebRTC and DTLS-SRTP media systems bind an application’s participant claim to an SDP fingerprint, DTLS certificate, private-key proof, and media authorization. It follows each transition from signaling and ICE through protected transport, then examines black-box testing and application-level impact. Strong ciphers do not fix admission of the wrong key: the USENIX study found DTLS-layer failures in 19 of 33 tested media-server implementations and demonstrated media or encrypted-metadata retrieval in 9 affected systems. These are bounded, mainly July 2025 observations, not an ecosystem prevalence rate.
Learning outcomes
- Encryption protects packets; authentication determines which endpoint is entitled to participate.
- The decisive chain binds signaling, fingerprint, certificate, private-key proof, DTLS state, and media authorization.
- A completed DTLS handshake proves a transcript and keys, not automatic permission to receive media.
- The USENIX study found DTLS-layer authentication failures in 19 of 33 tested media-server implementations; 9 affected systems yielded media or encrypted metadata.
Keywords
Preview every chapter · Unlock full text, audio, and video from chapter 4
PlansFAQ
Why can encrypted WebRTC media reach the wrong peer?
Encrypted WebRTC media can reach the wrong peer when a server accepts an attacker-controlled key without preserving the signaling-to-certificate identity binding. The channel can remain confidential and integrity-protected while its authorization points to the wrong participant.
What does the SDP fingerprint prove in WebRTC?
The SDP fingerprint identifies the certificate that this session expects, not a person by itself. The DTLS endpoint must match the presented certificate to that fingerprint and verify private-key possession; an optional identity assertion can add a higher-level user or account claim.
Does a completed DTLS handshake prove that media access is authorized?
No. A completed DTLS handshake shows that the protocol produced keys and verified the transcript it processed, but the application must still bind the connection to the right participant, stream, and call before releasing media.
How can WebRTC media-server authentication be tested?
It can be tested from a controlled Man-in-the-Middle position by perturbing certificates, signatures, message order, and key associations, then continuing the real application flow. A defensible result separates a handshake bypass from observed media or encrypted-metadata release and records transport and application limits.