ASVS 5.0 V17.2.2 requires that the media server is configured to use and support approved DTLS cipher suites and a secure protection profile for DTLS-SRTP key establishment. It is a Level 2 requirement.
DTLS negotiates a cipher suite for the handshake, and the use_srtp extension negotiates the SRTP protection profile that encrypts and authenticates the media. Both need to be strong, and weak options should be switched off.
Why it matters
Servers that accept everything a client offers can be downgraded to weak or deprecated algorithms. A weak SRTP profile, such as one with a short authentication tag or no encryption, weakens the protection of every call.
How to implement it
Decide your approved list in the key management or crypto policy, then configure the server to it. Reasonable choices today: DTLS 1.2 or newer, ECDHE key exchange with AES-GCM suites, and the SRTP profile SRTP_AEAD_AES_128_GCM or SRTP_AES128_CM_SHA1_80 for compatibility. Prefer the AEAD profile where clients support it.
OpenSSL based servers can set this directly:
SSL_CTX_set_cipher_list(ctx, "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256");
SSL_CTX_set_tlsext_use_srtp(ctx, "SRTP_AEAD_AES_128_GCM:SRTP_AES128_CM_SHA1_80");
Do not offer null encryption or profiles with a 32 bit authentication tag unless a documented exception exists. Keep the library patched, and recheck settings after every upgrade because defaults change.
How to test it
Connect with a DTLS test client (for example openssl s_client -dtls1_2 -use_srtp SRTP_AES128_CM_SHA1_80) and record what is negotiated. Then offer only weak ciphers and a weak profile and confirm the handshake fails. Capture a call in a browser and read the negotiated profile in chrome://webrtc-internals.
Keeping the list current
Cryptographic guidance moves. Put a review of the approved DTLS and SRTP list on the calendar, once or twice a year, and after any advisory that touches your TLS library. Record the date and the reason for each change so an auditor can see the history.
Interoperability matters because browsers drive what clients offer. Current browsers support DTLS 1.2 and AEAD profiles, so you can prefer them and treat older profiles as a compatibility fallback you may remove later. Measure which profile each real call negotiates, then retire the unused ones.
Common mistakes
- Leaving library defaults and never reading them.
- Allowing legacy DTLS 1.0.
- Offering a profile with no authentication to support one old device.
- Testing only the happy path, never the downgrade.
Quick check
What does the use_srtp extension do?
It lets client and server agree on the SRTP protection profile and derive media keys from the DTLS handshake.
