ASVS 5.0 V17.2.6 requires that the media server is not susceptible to the DTLS ClientHello race condition. You verify this either by checking whether your server version is publicly known to be vulnerable, or by performing the race condition test. It is a Level 3 requirement.
In short: during connection setup, an attacker who can reach the media port may be able to get a hostile DTLS ClientHello processed ahead of the real client's, which can break or hijack the handshake for that session. Whether a given server is affected depends on its implementation and version.
Why it matters
DTLS runs over UDP, and the media port is reachable from the internet. If the server binds a session too early, or accepts a handshake from an address other than the one validated by ICE, a third party can interfere with a call that is just starting. The result ranges from failed calls to a poisoned session, depending on the flaw.
This is a class of bug that is fixed in libraries and servers by patches. Your job is to know what you run and whether it is patched.
How to implement it
- Inventory your media stack: the media server, its DTLS library (OpenSSL, mbedTLS, GnuTLS, or a built in stack) and the WebRTC library underneath it. A dependency inventory is the starting point.
- Check each against vendor advisories for ClientHello race or handshake hijack issues, and upgrade to fixed releases.
- Restrict DTLS handling to the remote address and port validated by ICE, and drop DTLS from other sources.
- Enable alerts for handshake failures per session, since a spike may indicate probing.
- Add the media stack to continuous vulnerability monitoring so new advisories reach you.
Click through it at your own pace, or open it full screen.
You can also run a free in-browser dependency scan at gold.safeguard.sh/scan on a manifest that lists your media components, and use reachability analysis to see which flagged packages your code actually calls.
How to test it
Version route: record the exact version of each component, compare with advisories, and keep the comparison as evidence.
Race route, in a lab you own:
- Start a session so ICE connectivity checks complete.
- From a second host, send a DTLS ClientHello to the media port before the legitimate client does, using a DTLS capable tool or a small script.
- Let the real client attempt its handshake.
- Pass when the real handshake succeeds, the spoofed one is rejected, and the session is not disrupted. Repeat many times, because races are timing dependent.
Keeping the knowledge current
A ClientHello race is the kind of issue that appears in advisories for individual products, and your stack may embed a library you did not choose. Subscribe to the security feeds of your media server and its DTLS library, and keep a living software inventory so you can answer in minutes which services carry which version. Re-run the lab race test after upgrades, because a refactor of handshake handling can reintroduce the problem.
Common mistakes
- Assuming the WebRTC library vendor already handled it.
- Testing once. A race can pass nine times and fail the tenth.
- Running the test in production.
- Not knowing which DTLS library is embedded in the server.
Quick check
What are the two ways to satisfy this requirement?
Check that your server version is not publicly known to be vulnerable, or run the race condition test against it.
