Summary
FreeSWITCH could fail to verify a peer's DTLS certificate against the SDP fingerprint when FreeSWITCH acted as the DTLS server. A peer able to reach the negotiated media port may then establish a session with an unrelated certificate, potentially exposing or allowing manipulation of media.
FreeSWITCH could fail to verify a peer's DTLS certificate against the SDP fingerprint when FreeSWITCH acted as the DTLS server. A peer able to reach the negotiated media port may then establish a session with an unrelated certificate, potentially exposing or allowing manipulation of media.
Affected context
The issue affects WebRTC and SIP DTLS-SRTP legs when the peer selects the active DTLS role and FreeSWITCH acts as the DTLS server. In that role, certificate-to-fingerprint verification was not performed during DTLS setup; FreeSWITCH client-role handshakes already performed the check. For ICE-enabled legs, an attacker also needs the connectivity-check credentials from SDP, which generally requires signaling visibility or a position on its path.
The issue affects WebRTC and SIP DTLS-SRTP legs when the peer selects the active DTLS role and FreeSWITCH acts as the DTLS server. In that role, certificate-to-fingerprint verification was not performed during DTLS setup; FreeSWITCH client-role handshakes already performed the check. For ICE-enabled legs, an attacker also needs the connectivity-check credentials from SDP, which generally requires signaling visibility or a position on its path.
Exploit preconditions
- Attack surface: A negotiated DTLS-SRTP media port reachable by the peer
- Required access: The issue does not inherently require authentication; ICE-enabled legs additionally require the SDP connectivity-check credentials
- Trigger point: A DTLS handshake on a leg where FreeSWITCH acts as the DTLS server and the peer selects the active role
- Why exploitation is possible: In this role, the peer certificate was not compared with the fingerprint advertised in SDP
- Attack surface: A negotiated DTLS-SRTP media port reachable by the peer
- Required access: The issue does not inherently require authentication; ICE-enabled legs additionally require the SDP connectivity-check credentials
- Trigger point: A DTLS handshake on a leg where FreeSWITCH acts as the DTLS server and the peer selects the active role
- Why exploitation is possible: In this role, the peer certificate was not compared with the fingerprint advertised in SDP
Why this happens
The DTLS setup logic applied peer certificate fingerprint verification only when FreeSWITCH was the DTLS client. Omitting the equivalent check in the server role allowed a certificate unrelated to the SDP fingerprint to be accepted. This is an improper certificate validation weakness (CWE-295) and can also enable a man-in-the-middle condition (CWE-300) by undermining the expected peer identity check.
The DTLS setup logic applied peer certificate fingerprint verification only when FreeSWITCH was the DTLS client. Omitting the equivalent check in the server role allowed a certificate unrelated to the SDP fingerprint to be accepted. This is an improper certificate validation weakness (CWE-295) and can also enable a man-in-the-middle condition (CWE-300) by undermining the expected peer identity check.
Potential impact
- An attacker may obtain SRTP keys and decrypt media
- An attacker could inject or alter media
- A malicious peer may displace the legitimate endpoint
- Calls or conferences may experience loss of confidentiality, integrity, or availability
- An attacker may obtain SRTP keys and decrypt media
- An attacker could inject or alter media
- A malicious peer may displace the legitimate endpoint
- Calls or conferences may experience loss of confidentiality, integrity, or availability
General mitigation guidance
Mitigation centers on validating peer identity consistently across DTLS roles.
Common defensive patterns include:
- Require certificate fingerprint verification for both client- and server-role handshakes
- Treat SDP fingerprints as security-critical identity data and protect signaling integrity
- Reduce exposure of negotiated media ports to untrusted networks where practical
- Limit the privileges and network access available to media-processing services
- Use secure-by-default DTLS-SRTP configurations that reject missing or mismatched identity checks
Mitigation centers on validating peer identity consistently across DTLS roles.
Common defensive patterns include:
- Require certificate fingerprint verification for both client- and server-role handshakes
- Treat SDP fingerprints as security-critical identity data and protect signaling integrity
- Reduce exposure of negotiated media ports to untrusted networks where practical
- Limit the privileges and network access available to media-processing services
- Use secure-by-default DTLS-SRTP configurations that reject missing or mismatched identity checks
How teams detect issues like this
Detection and review can focus on:
- Static analysis and code review for role-dependent branches that skip certificate or fingerprint checks
- Tests confirming that mismatched fingerprints are rejected in both DTLS roles
- Configuration and policy checks requiring fingerprint verification for DTLS-SRTP
- Monitoring for unexpected DTLS peers, endpoint replacement, or anomalous media-session behavior
Automated security review tools may help identify asymmetric validation paths.
Detection and review can focus on:
- Static analysis and code review for role-dependent branches that skip certificate or fingerprint checks
- Tests confirming that mismatched fingerprints are rejected in both DTLS roles
- Configuration and policy checks requiring fingerprint verification for DTLS-SRTP
- Monitoring for unexpected DTLS peers, endpoint replacement, or anomalous media-session behavior
Automated security review tools may help identify asymmetric validation paths.
