skip to content

In DTLS-SRTP, what does the SDP a=fingerprint attribute bind, and why does media security still depend on the signalling path?

level: seniorimportance: should knowfreq 15%

answer

  1. self-signed certificates on both ends
  2. hash of the certificate in SDP
  3. mismatch ends the media session
  4. whoever can rewrite the SDP

basics

~20 s

The a=fingerprint attribute carries a hash of the certificate each endpoint will present in the DTLS handshake, so self-signed certificates can be trusted. Whoever can alter the SDP can substitute a fingerprint and sit in the middle, so signalling needs integrity.

solid answer

~40 s

DTLS-SRTP endpoints usually present self-signed certificates, so trust cannot come from a certification authority. Instead each side puts `a=fingerprint:sha-256 <hex>` in its SDP, a hash of the DER-encoded certificate as defined by RFC 8122 (which obsoletes RFC 4572). During the handshake each endpoint hashes the certificate it receives and compares; RFC 5763 requires the media session to be torn down on a mismatch. That binds the media keys to whoever wrote the SDP, not to a person. Anyone who can modify the SDP, such as a compromised proxy or the signalling server itself, can insert its own fingerprint and, if it can also reach the media path, terminate both handshakes unseen. The signalling therefore needs integrity, though not confidentiality; identity assertions, key-continuity caching or out-of-band comparison reduce trust in the signalling service.

go deeper

for a junior

Recall that a=fingerprint is a hash of the endpoint's certificate sent in SDP, so the peer can check the certificate it sees in the DTLS handshake.

for a middle

Explain the check order: fingerprints in offer and answer, certificates in the handshake, hash and compare, tear down on mismatch, and SHA-256 as the preferred hash.

for a senior

Show the trust boundary: whoever can rewrite SDP and reach the media path can interpose, so signalling integrity, identity assertions and key continuity decide real security.

for a principal

Weigh the options for reducing trust in the signalling service, such as identity providers, continuity caching against per-call keys, and their usability and privacy costs.

## The problem the fingerprint solves A DTLS handshake authenticates peers with **X.509 certificates**. Ordinary TLS trusts a certificate because a certification authority signed it for a name the client expected. Media endpoints rarely fit that model: browsers, phones and gateways have dynamic addresses, often no stable name, and no practical way to obtain a CA-signed certificate per session. RFC 8122 therefore lets endpoints use **self-signed certificates** safely, *provided the integrity of the SDP is assured*. The session description becomes the prior relationship: if it arrives unaltered, the certificate it describes is the right one. ## What is on the line The attribute is `a=fingerprint:<hash-func> <fingerprint>`, for example: ``` a=fingerprint:sha-256 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB:3E:5D:49:6B:19:E5:7C:AB:4A:AD:B9:B1 ``` - The value is a hash of the certificate's **DER encoding**, written as colon-separated uppercase hexadecimal bytes. - **SHA-256 is the preferred hash.** RFC 8122 moved the preference from SHA-1 and forbids MD2 and MD5 for computing or verifying fingerprints. - An endpoint must at least provide a SHA-256 fingerprint and one using the hash of the certificate's own signature algorithm, though either may be omitted under the conditions RFC 8122 lists. - Several fingerprints may sit on one media section, for several hashes or several certificates. The receiver picks the set using its most preferred hash among those offered and requires each certificate to match one of them. - The attribute may be session-level or media-level; a media-level one wins. ## What each endpoint does 1. The offerer puts its fingerprint in the offer and must be ready for a ClientHello before the answer arrives. 2. The answerer's fingerprint comes back in the answer. 3. Both certificates are exchanged in the DTLS handshake; RFC 8122 requires the TLS server to request a client certificate in the offer/answer model. 4. Each side hashes the certificate it received and compares it with the peer's signalled fingerprint. 5. On a mismatch, RFC 5763 says the endpoint **must tear down the media session immediately**. An offerer that finished the handshake before the answer arrived must not trust the data until a matching fingerprint does arrive. Only after this check do the keys exported from the handshake protect the media. ## Who you are trusting | Attacker capability | Outcome | |---|---| | Passive observer of the media path | Sees only DTLS and SRTP ciphertext | | Active on the media path only | Its certificate does not match the fingerprint; the session is torn down | | Can modify the SDP and reach the media path | Substitutes its own fingerprints and relays both handshakes unnoticed | | Operates the signalling service | Can do the same unless something verifies keys independently | RFC 5763 states that without signalling integrity the protection is limited to passive attacks; an active attack on signalling plus media defeats it. RFC 8827 adds that without HTTPS to the signalling server and without an identity mechanism, any on-path attacker can replace the fingerprints, and that even with HTTPS the signalling server itself can interpose unless keys are verified independently. ## Narrowing that trust - **Integrity-protected signalling.** HTTPS for WebRTC; for SIP, SIP Identity signatures or S/MIME resist modification by intermediaries, while SIPS gives hop-by-hop protection that trusts every proxy. - **Identity assertions.** WebRTC can bind the fingerprint to an identity issued by a third-party identity provider; a malicious signalling service can strip an assertion but cannot forge one. - **Key continuity.** RFC 5763 recommends keeping a long-term certificate per peer, caching it and warning when it changes, much as SSH does. That pulls against RFC 8827's default of a new key pair per call, chosen for unlinkability, which an application may override. - **Out-of-band comparison** of fingerprints or a short authentication string, workable for careful users but not at scale. The fingerprint authenticates the key exchange; it does not provide secrecy on its own. Forward secrecy comes from the DTLS cipher suite's ephemeral Diffie-Hellman exchange. ## What an operator watches - **Teardowns by reason.** A rise in certificate-mismatch teardowns after ICE succeeded points at rewritten or stale SDP, or at an interception attempt. - **Certificate changes.** A media server or gateway that rotates its certificate must signal the new fingerprint; under RFC 8842 a changed fingerprint in an offer or answer means a new DTLS association. - **The signalling path itself.** Since the fingerprint is only as good as the SDP that carried it, the signalling server's access controls and transport security are part of media security.

  • Why are self-signed certificates acceptable for DTLS-SRTP when they are not for an ordinary web server?
    Because trust is anchored in the SDP rather than in a certification authority. If the description arrives unaltered, the fingerprint inside it is the prior relationship that tells the endpoint which certificate to expect. A CA-signed certificate adds little unless the endpoint also checks a name tied to the call, and media endpoints rarely have stable names to certify.
  • How can a DTLS-SRTP endpoint detect a fingerprint substitution when it cannot fully trust the signalling service?
    By verifying the key through something the signalling service cannot forge: an identity assertion from a third-party identity provider bound to the fingerprint, a cached certificate for a known peer with a warning when it changes, or out-of-band comparison of fingerprints. Each narrows trust; a hostile service can still strip assertions, so their absence must be visible.
  • What does a fingerprint mismatch look like to an operator investigating a silent call?
    Signalling completes and ICE connectivity checks succeed, then the DTLS handshake reaches the certificate comparison and the endpoint tears the media session down. The call appears answered but carries no media. The cause is usually a stale or rewritten SDP, a gateway presenting a different certificate than it signalled, or a deliberate interception attempt.

saying these in an interview costs you the question

  • The fingerprint encrypts the SDP so the signalling server cannot read the keys.
  • DTLS-SRTP is insecure unless both certificates are signed by a public CA.
  • Keys made on the media path mean a malicious signalling server cannot intercept the call.
  • A fingerprint mismatch is logged as a warning while the media continues.
  • MD5 fingerprints are fine because the hash only identifies the certificate.