Safeguard
Application Security•

ASVS 5.0 V17.2.8: Check the DTLS Certificate Against the SDP Fingerprint

ASVS V17.2.8 requires comparing the DTLS certificate with the SDP fingerprint and ending the stream on mismatch. Code, test and common mistakes.

Safeguard Security Team
3 min read

ASVS 5.0 V17.2.8 requires that the DTLS certificate is checked against the fingerprint attribute in the Session Description Protocol (SDP), and that the media stream is terminated if the check fails. It is a Level 3 requirement.

The SDP travels over signaling and carries a line like a=fingerprint:sha-256 AB:CD:.... The DTLS handshake presents a certificate. If the hash of that certificate does not match the fingerprint, the peer is not who signaling said it was.

Why it matters

DTLS certificates in WebRTC are normally self signed, so there is no certificate authority to vouch for them. The fingerprint, delivered over the authenticated signaling channel, is the only binding between the signaled peer and the media peer. Skip the check and a man in the middle on the media path can terminate DTLS itself and read or alter the call.

How to implement it

After the handshake completes, hash the peer certificate in DER form with the algorithm named in the SDP, compare in constant time, and close the session on mismatch. Reject weak hash algorithms such as sha-1 and prefer sha-256.

import hashlib, hmac

def fingerprint_ok(cert_der: bytes, sdp_value: str) -> bool:
    algo, _, hexpart = sdp_value.strip().partition(" ")
    if algo.lower() != "sha-256":
        return False
    expected = bytes.fromhex(hexpart.replace(":", ""))
    actual = hashlib.sha256(cert_der).digest()
    return hmac.compare_digest(actual, expected)

# after handshake:
if not fingerprint_ok(peer_cert_der, remote_sdp_fingerprint):
    session.close()
    log.error("dtls_fingerprint_mismatch session=%s", session.id)

Remember that the guarantee depends on signaling being authenticated and protected with TLS. A fingerprint received over an unauthenticated channel proves nothing. Also handle renegotiation: when SDP changes, update the expected value atomically.

How to test it

  1. Establish a call normally and confirm it works.
  2. Alter the fingerprint in the SDP the server receives, flipping one hex digit. The handshake should complete at the TLS layer but the session must be closed and a mismatch logged.
  3. Present a different valid certificate from the peer. Same expected result.
  4. Offer sha-1 only and confirm rejection if policy forbids it.
  5. Confirm no media is forwarded between the mismatch and the close.

Edge cases worth testing

Several details cause real failures. The fingerprint is computed over the DER encoded certificate, not the PEM text. The hex is colon separated and case is not significant in SDP, so normalize before comparing. A session may contain multiple media sections, each with its own fingerprint line, or one at session level that applies to all; handle both. When the browser performs an ICE restart or renegotiation, the fingerprint may change, so update the expected value when you receive the new SDP and verify it again on the next handshake.

Logging and response

A mismatch is a security event. Log session id, peer address and which fingerprint was expected, without logging the certificate private material. Alert on repeated mismatches from the same source, which suggests an active interception attempt.

Common mistakes

  • Verifying that a certificate exists but never comparing it.
  • Comparing with a plain equality check on strings in a different case or format.
  • Signaling over plain WebSocket, which lets an attacker rewrite the fingerprint.
  • Closing the session but still forwarding the first packets.

Quick check

Why is the check meaningless without secure signaling?

An attacker who can change the SDP can also change the fingerprint to match their own certificate.

What must happen on a mismatch?

The media stream is terminated and the event is logged.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.