Strong Ciphers, Weak Admission

The DTLS-MitM-Scanner shows that authentication failures can be measured separately from the cryptographic algorithms a deployment advertises. This chapter interprets that separation in the tested WebRTC ecosystem: which protocol and cipher choices were generally modern, where certificate and negotiation behavior remained uneven, and what the study’s different denominators actually support. The goal is not to rank every service, but to explain why a strong transport can still admit the wrong peer.

A modern cryptographic baseline, operated unevenly

At the algorithm level, the tested ecosystem was not a story of universal obsolete cryptography. DTLS 1.2 was supported by every tested implementation, while DTLS 1.0 appeared only in Adobe Connect. DTLS 1.3 support was effectively absent during the experiments. The paper notes that Firefox had later added DTLS 1.3 support but that the tested Firefox 137 configuration did not have it enabled, suggesting a version-specific problem rather than a stable ecosystem conclusion.

The tested implementations generally supported forward-secure key exchange and authenticated-encryption cipher suites. The researchers generally did not observe support for conspicuously weak choices such as NULL or EXPORT suites. WebRTC’s baseline also requires support for a particular DTLS 1.2 ECDHE-ECDSA and AES-GCM combination, and its security architecture says implementations must favor forward secrecy and should favor AEAD over older non-AEAD choices. This is meaningful protection: if the endpoint identities are correct, forward secrecy and authenticated encryption make passive interception and packet tampering substantially harder.

The same measurements revealed operational rough edges. Some servers advertised a cipher suite and selected it in the ServerHello, then sent an alert when trying to produce the certificate. The study attributes many of these failures to a mismatch between the key type required by the selected suite and the certificate the server had committed to use in SDP. A server can therefore appear to support a modern option in a capability probe while failing when that option reaches the next state of the handshake. The issue is not necessarily a broken cipher; it is a disagreement between configuration layers.

Negotiation preference was also not uniformly enforced. Many implementations relied on the order of the client’s proposed list instead of enforcing a server-preferred order. That gives the browser or other client more influence over the selected algorithm than a reader might infer from the presence of a server configuration. It also illustrates a broader systems point: the security result is jointly determined by the values offered, the values accepted, the order in which they are selected, and the credentials available to complete the selected path.

SRTP profiles showed a similar mixture of stability and variation. Tested browsers supported the mandatory SRTPAES128CMHMACSHA180 profile and the AES-GCM profiles. Firefox also supported a 32-bit HMAC profile, whose short authentication tag makes forgery easier if it is selected.