The Fingerprint Binding: Why Encryption Can Still Name the Wrong Peer
For a WebRTC media server, the hard identity problem is not that certificates are self-signed. It is that several different claims have to refer to the same key and the same call. This chapter isolates the bridge between an application’s signaling message and the certificate presented in DTLS: what an SDP fingerprint commits to, how an optional identity assertion adds a claim about a user or account, and how the checks fail when those layers are confused. The result is a practical distinction between a key that is strong, a key that is privately held, and a key that the call actually authorized.
A self-signed certificate becomes meaningful through the fingerprint
A conventional HTTPS connection usually begins with a certificate chain that a browser validates against a public trust store. WebRTC’s peer certificates work differently. An endpoint can generate a self-signed X.509 certificate and its private key for a call, place a fingerprint of the certificate in SDP, and later present the certificate during the DTLS handshake. The peer does not need a public certificate authority to recognize the certificate. It needs to compare the certificate it receives with the fingerprint that was committed during signaling.
That arrangement is not a shortcut around authentication. It moves the trust decision to a different boundary. The certificate says, “this public key belongs to this certificate.” Possession of the corresponding private key lets the endpoint prove control of that key during DTLS. The fingerprint says, “this is the certificate that the call description expected.” Only the combination connects the proof of key possession to the particular session that the application proposed.
The fingerprint is usually understood as a compact digest of the certificate. Its value is not that a reader can recognize the digest by sight; its value is that changing the certificate changes the value that a correct implementation compares. A server or browser does not need to trust the certificate because it was issued by a familiar company. It needs to reject the certificate if it does not match the expected fingerprint, even when the certificate is otherwise well formed.
This is why the comparison belongs to the peer that will use the DTLS connection. The signaling service can carry a fingerprint, but it does not thereby prove that the endpoint at the other side of a later packet flow has the corresponding private key. The DTLS endpoint receives the certificate, verifies the protocol signatures and key exchange, and checks that the certificate is the one named in the signaling state. A media server that skips the last comparison can complete a technically valid handshake with a key that the application never authorized.
The check also has to be made against the right object. A certificate subject, issuer, common name, or operating-system trust decision is not a substitute for the fingerprint associated with this call. A certificate can be issued by a legitimate public authority and still be unrelated to the session. Conversely, a self-signed certificate can be the correct certificate for a session if its fingerprint was delivered through a trusted signaling path and the peer verifies the match. The relevant question is not “Does someone trust this certificate somewhere?” It is “Is this the certificate that this session committed to use?”
The private-key proof is a second, separate check. During an authenticated DTLS exchange, a certificate alone should not be enough: the endpoint must demonstrate control of the private key through the signatures required by the negotiated handshake. The client’s proof covers the handshake transcript in the paper’s description; the server’s ephemeral key exchange is signed with the server certificate’s private key. A peer that accepts a certificate without requiring or validating the relevant proof has learned the public key but not established that the connecting party controls it.
The distinction can be expressed as a chain of questions. The signaling layer supplies the expected certificate. The DTLS layer asks whether the endpoint presents that certificate and proves possession of its key. The media layer asks whether the authenticated connection is authorized for this participant and stream. A failure at the first question can permit an attacker to substitute a key. A failure at the second can permit a party without the key to pass as its owner. A failure at the third can allow a correctly authenticated connection to be mapped to the wrong application state. All three can produce an encrypted channel, but they do not produce the same security property.
The binding is easier to see when its success and failure paths are placed side by side:
The diagram is not a claim that the protocol has one universal implementation function for every arrow. It is a security relationship. Different software components may own the signaling state, the DTLS state, and the media authorization state. The system is safe only if those components preserve the relationship rather than each checking a nearby but different property.
Identity claims sit above the key, and trust has failure modes
A fingerprint identifies a key pair for a session. It does not, by itself, say whether that key belongs to a person named by an address book, an account, or a service role. RFC 8827 describes an optional web identity mechanism for adding that higher-level claim. An endpoint can put an identity assertion in the SDP identity attribute. The assertion is consumed by an identity provider or proxy, and the architecture requires it to be bound to the session’s fingerprint. The receiving browser can then verify not only that the peer controls a particular key, but also that an identity service associates that key with a claimed identity.
That extra assertion does not replace the fingerprint check. It depends on it. If an identity service attests to Alice while the media endpoint uses an attacker-controlled key, then the attestation has been detached from the key that protects the call. Conversely, if the fingerprint is correct but the identity assertion is absent, the endpoints may still have a cryptographically bound channel while offering a lower level of assurance about who is using it. Authentication of a key and authentication of a person are related decisions, not interchangeable labels.
The RFC’s format reflects that separation. The SDP identity value contains an encoded assertion and information identifying the identity provider. The assertion may bind the user identity to the fingerprint and possibly other session information. When an endpoint receives an offer or answer carrying an identity attribute, it can contact the relevant provider to verify it; if verification fails, the offer or answer is to be discarded as malformed. This is a strong rule, but it assumes that the identity mechanism is deployed and that the browser enforces the relationship between the assertion and the fingerprints.
The standards document is candid about that assumption: its web-based peer-authentication mechanism was not widely adopted or implemented at publication. A deployment may therefore rely mainly on the calling service’s signaling claims and the DTLS fingerprint path, or use application-specific identity and authorization. That does not make the fingerprint unimportant. It makes the boundary more visible. Without a widely used independent identity service, the signaling service and the media endpoint must be especially careful not to turn an application label into an unaudited certificate decision.
Signaling transport is another trust layer. RFC 8827 states that if HTTPS is not used to protect signaling and an independent identity mechanism is absent, an on-path attacker can replace the DTLS-SRTP fingerprints and substitute an attacker-controlled identity. The attacker does not need to break SRTP. They alter the value that the later DTLS certificate will be compared against, then complete a separate handshake with their own key. The resulting media may be encrypted exactly as designed, but the design has been made to encrypt the attacker’s endpoint into the call.
HTTPS narrows that threat but does not settle every trust question. Even with protected signaling, the signaling server may be able to mount a man-in-the-middle attack if peers have no independent way to verify keys. The RFC’s identity mechanism is intended to provide such an independent relationship: an identity provider can attest to the fingerprint without relying entirely on the calling service. A malicious signaling service may be able to strip an identity assertion, which reduces assurance, but it cannot simply forge a new valid assertion if the identity provider is functioning correctly. Users who need protection from a malicious identity provider require a stronger out-of-band check, such as comparing a fingerprint directly.
Fingerprint changes illustrate why identity cannot be stored as a loose label. If the set of fingerprints remains unchanged while a session is modified, the previously established identity can continue to apply to existing and new DTLS connections using those fingerprints. If the fingerprint set changes, the sender must provide a new identity assertion or none at all, and the receiver must discard previously established identity information. The reason is structural: a new key changes the cryptographic endpoint to which the old identity was attached. Keeping the old name without a new binding would silently turn identity continuity into identity reuse.
The same logic applies to key lifetime. The RFC says a new authentication key pair should be generated for each call by default, while still allowing deliberate reuse for key continuity. New keys reduce linkability and make it harder for an identity to persist accidentally across sessions. Reuse can provide continuity and reduce generation costs, but it enlarges the consequences of a stale or misapplied binding. Either choice requires the implementation to know which identity is attached to which key and for how long.
There are also browser boundaries around these claims. The security architecture treats the browser as the trusted computing base for properties the user expects it to enforce. Content JavaScript must not obtain DTLS keying material or perform operations that depend on secret key information. Otherwise, a page could obtain an identity assertion for one browser-generated key and use the associated signing capability with a different key it controls. The browser’s refusal to expose the secret operation is therefore part of the binding: the page may request a call, but it must not be able to move an authenticated identity onto arbitrary keying material.
These layers make several superficially similar certificate failures materially different. An unrelated certificate tests whether the peer checks the expected fingerprint at all. A mimicry certificate tests whether it is checking the public-key binding rather than a superficial subject or issuer field. A certificate from a normal Internet certificate authority tests whether software has incorrectly consulted a general trust store instead of the call-specific fingerprint. An invalid signature tests whether the endpoint verifies proof of private-key possession. The tests all present certificates, but each asks a different question about the binding.
Certificate strength is another nearby property that must not be substituted for authorization. A 2048-bit or elliptic-curve certificate can be difficult to break and still be the wrong certificate for the call. A weak certificate can make key recovery or impersonation easier, but strengthening its modulus does not repair a server that accepts any certificate or compares the wrong fingerprint. The study reports that tested browsers accepted a 512-bit RSA certificate from a test media server, a sign of permissive certificate handling. That observation matters, but it is not by itself proof that every such certificate caused a media leak; the outcome still depends on fingerprint validation, private-key proof, and application authorization.
The diagnostic rule is consequently precise: first ask which certificate the signaling state authorized, then ask whether the DTLS peer presented it, then ask whether the peer proved control of its private key, and finally ask what the application authorized that connection to do. If any answer is replaced with “the certificate looked familiar,” “ICE succeeded,” or “the cipher was strong,” the system may have preserved encryption while losing identity.
Those separate invariants are what make the empirical study useful. Rather than treating “certificate validation” as one opaque feature, the researchers tested missing certificates, optional authentication, unrelated and mimicry certificates, trust-store misuse, signature verification, message flow, and public-key protection. The next chapter follows how those tests can be performed against real applications from a Man-in-the-Middle position without obtaining their private keys.