A Completed Handshake Is Not Yet a Media Leak
A DTLS authentication bypass tells us that a media server accepted the wrong cryptographic peer. It does not, by itself, tell us whether the application then released anyone’s audio or video. This chapter follows that second boundary in the WebRTC study: what an attacker must do after the handshake, why the Webex proof of concept crossed the boundary, and why other tested services stopped at metadata, control traffic, or a later application check. The distinction lets us take the server findings seriously without treating every protocol-layer failure as the same user-visible compromise.
The handshake is a gate, not the room
A completed DTLS handshake creates a protected channel between two endpoints. In a media-server deployment, it does not necessarily create permission to receive a participant’s media. The application may keep its own record of who was invited, which stream belongs to which participant, and what messages must arrive before forwarding begins. The DTLS library can report success while the application still considers the connection untrusted, incomplete, or unrelated to the call state.
The study identifies three main reasons for this gap. First, an implementation can perform delayed client authentication after the handshake. It may accept the connection provisionally, inspect its state or certificate later, and terminate it before transmitting sensitive content. Second, the application may wait for an application-layer signal from the other side. A peer may need to complete a data-channel setup, send a service-specific control message, or reach a state that the attacker’s altered handshake did not establish. Third, the application may use cryptography of its own above DTLS. In that design, the DTLS channel is only a transport for another authentication or key-establishment step.
From the server’s perspective, these checks belong to different state stores even when they are triggered by the same incoming packet flow. One state says that a DTLS transcript completed and produced keys. Another says that a participant has joined a particular meeting. A third maps synchronization-source identifiers to audio or video streams. A fourth records whether an application control message has authorized forwarding. A fifth tracks whether the ICE path remains consented. A connection can pass one state and fail the next. That is why a packet trace showing Finished messages cannot, on its own, answer whether media should have been released.
This separation also explains why a later application check is a containment measure rather than a repair of the lower-level identity problem. If the server authenticates the wrong DTLS peer and then refuses to send media, the immediate confidentiality impact may be limited. But the application is still relying on a hidden assumption that the lower layer might be correct in future versions or on another path. If a new control message, stream mapping, or transport fallback bypasses the later check, the old DTLS weakness can become exploitable. The security argument is strongest when every layer checks the binding it owns and fails closed when an earlier layer did not establish it.
Even when no additional cryptography exists, media protocols impose their own conditions. Discord’s media server required a valid SRTP message with the correct synchronization-source identifier before it started sending media in the tested path.