WebRTC DTLS fingerprints are only an identity boundary when signaling is trusted

WebRTC media is protected with DTLS-SRTP. During signaling, each endpoint places a certificate fingerprint in the session description. The DTLS handshake then presents a certificate, and the other endpoint checks that the certificate matches the signaled fingerprint. This binds the encrypted media channel to the identity material exchanged through signaling.

RFC 8827 describes the security architecture. It requires DTLS-SRTP for keying SRTP and says implementations must not offer or select SDP security descriptions. The specification also explains that the PeerConnection must provide the DTLS-SRTP fingerprint for binding to an identity. The fingerprint is not a user identity by itself. It is a link between the media handshake and the signaling message that delivered the fingerprint.

That link is only as strong as the signaling channel. RFC 8827 warns that if signaling is not protected by HTTPS and no identity mechanism is used, an on-path attacker can replace the fingerprints and substitute its own identity. A JavaScript application can enforce HTTPS for its own origin, yet still accept session descriptions from a compromised signaling server, a malicious application component, or an unauthenticated WebSocket peer.

A practical review follows the fingerprint from creation to use:

1. Confirm how the browser or native client generates the DTLS certificate and whether it is reused across sessions.
2. Capture the fingerprint in the local session description and locate every path that transports it.
3. Verify that the signaling endpoint authenticates the participants and associates messages with the correct session.
4. Confirm that the receiving endpoint compares the certificate fingerprint before accepting media.
5. Check whether an offer, answer, or renegotiation can replace the fingerprint after the initial exchange.

The identity mechanism is separate from media encryption. A conference service may authenticate users for the web application but still allow one participant to inject a session description into another participant's room. A peer-to-peer application may verify the signaling server's TLS certificate but not the identity of the participant who sent the answer. Encryption protects the media from passive observers; it does not repair a malicious signaling message.

Tests should include altered fingerprints, duplicate session identifiers, stale offers, and answers from the wrong participant. Use a browser's real PeerConnection implementation rather than a mock that omits certificate generation. Confirm that a mismatched fingerprint causes the connection to fail and that the failure is logged without including sensitive ICE or certificate data.

WebRTC has strong cryptographic building blocks, but its trust path crosses application signaling. The DTLS fingerprint is useful when the application treats signaling as an authenticated, session-bound channel and rejects any attempt to replace the fingerprint outside that context.

References

• RFC 8827: WebRTC Security Architecture
• RFC 8826: Security Considerations for WebRTC