WebRTC Security Guide: TURN Servers, Media Encryption and Signalling

WebRTC encrypts media between browsers by default, yet most real WebRTC incidents come from the parts the browser does not control: the TURN relay, the signalling server and the media servers an operator runs. A misconfigured TURN server is an authenticated open proxy into the network it sits in, a signalling service can silently swap encryption keys, and a media server that falls over on malformed packets takes every call with it. This guide covers the WebRTC security model as the IETF defines it, then the operator side: hardening TURN, protecting DTLS-SRTP keys and fingerprints, securing signalling, controlling IP address exposure, and monitoring. It is written for engineers who build or run voice, video, contact centre and real-time data products, and for the security teams who assess them against OWASP ASVS 5.0, which now has a dedicated WebRTC chapter (V17).

Key takeaways

• Browser media encryption is mandatory, not optional. RFC 8827 requires DTLS-SRTP on every media channel, forbids SDES key exchange and plain RTP, and secures data channels with DTLS.
• The signalling server is inside the trust boundary. It carries the DTLS fingerprints, so a compromised or malicious signalling service can man-in-the-middle calls unless endpoints verify keys another way.
• TURN servers must not relay to internal addresses. ASVS V17.1.1 requires blocking reserved ranges for IPv4 and IPv6; a public bug bounty case showed a TURN relay reaching internal hosts and cloud instance metadata.
• TURN credentials are machine credentials. Use short-lived credentials derived from a shared secret, keep the secret in a secrets manager, and set per-user quotas.
• Availability is a security requirement. ASVS V17.2 and V17.3 expect media and signalling servers to keep working under floods and malformed packets.

How WebRTC is put together

A WebRTC session has four moving parts, and each has a different owner and threat model. The browser (or native SDK) implements the media stack and is responsible for encryption and permissions. Everything else is application infrastructure.

Two consequences follow. First, in a server-mediated call (any SFU or recording setup) the media server decrypts media, so "end-to-end encryption" claims only hold if an additional layer such as insertable streams with keys the server never sees is used. Second, the browser's guarantees stop at the browser: RFC 8827 assumes the signalling and relay infrastructure may be hostile and designs around that, while many deployments quietly trust it.

The browser security model (RFC 8827)

RFC 8827, WebRTC Security Architecture, is a Standards Track RFC published in January 2021. Its main requirements, which every compliant browser implements, are:

• Media encryption: DTLS-SRTP MUST be offered for every media channel; plain RTP and RTCP and NULL cipher suites are prohibited. Implementations MUST NOT offer SDP security descriptions (SDES), which would expose keys to the signalling path.
• Cipher baseline: DTLS 1.2 with TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 on P-256 must be supported; DTLS renegotiation and TLS False Start are prohibited. Keying material is not exposed to JavaScript, and a fresh key pair is generated per call by default.
• Fingerprint binding: each side places the hash of its DTLS certificate in the SDP fingerprint attribute; the DTLS handshake must match it. This is what ties the encrypted stream to the session the signalling negotiated.
• Consent and liveness: browsers verify reachability with ICE before sending non-ICE traffic, and must send periodic consent freshness checks (RFC 7675); if consent fails and no new path can be found, the session ends. This stops WebRTC being used to blast traffic at a target that never agreed to receive it.
• Device permissions: camera and microphone require explicit user consent, are never granted to HTTP origins, and the browser must show when they are in use.
• Identity: an identity provider mechanism (IdP proxy at /.well-known/idp-proxy/) can bind a user identity to the fingerprints, but the RFC itself notes it has not been widely adopted or implemented.

The practical gap is the last point. Because identity assertions are rarely deployed, the RFC's warning applies to most applications: even over HTTPS, the signalling server can substitute its own fingerprints and sit in the middle of the call. Protecting the signalling server is therefore protecting the encryption.

Hardening TURN servers

A TURN server accepts an authenticated client and relays packets to any peer address the client asks for. If nothing restricts the peer address, the client can reach whatever the TURN server can reach: its own loopback services, other hosts on the private network and, in the cloud, the instance metadata endpoint. Enable Security reported exactly this against Slack's TURN servers in 2018 (published April 2020): any user able to obtain TURN credentials could relay TCP and UDP to internal AWS hosts and the metadata service, which can expose temporary IAM credentials. Slack patched it. The lesson is that TURN is an SSRF and proxy surface, not just a media component. See the SSRF Prevention Guide and the EC2 Instance Metadata Service Hardening Guide.

• Network placement: run TURN in its own subnet or VPC with egress rules that allow only the internet and the named media servers. Peer IP filtering in the TURN daemon and network egress controls should both exist, because filter bypasses in TURN software have been published before.
• Port ranges: RFC 8656 says relay ports should come from 49152 to 65535, avoid 0 to 1023, and be randomised.
• Testing: include a TURN relay test in every penetration test: authenticate with valid credentials and confirm that loopback, RFC 1918, link-local (including 169.254.169.254) and IPv6 equivalents are refused. Do this only on systems you are authorised to test.

TURN credentials as non-human identities

The coturn "TURN REST API" scheme is the common pattern: the application backend, which already knows the user, issues a username of the form timestamp:userid and a password that is the base64 HMAC of that username under a shared secret. The TURN server recomputes the HMAC, so no user database is needed and credentials expire on their own. That makes the shared secret a high-value machine credential: anyone holding it can mint unlimited TURN access.

• Store the secret in a secrets manager and inject it at runtime into both the credential-issuing service and the TURN servers; never put it in client-side code or the coturn file in a repository.
• Keep credential lifetimes short (minutes to a few hours, matching call length) and include the user ID so abuse can be attributed and quotas applied per user.
• Rotate the secret on a schedule and immediately after any suspected leak; coturn can read it from its database (turn_secret table) so rotation does not require a restart.
• Issue credentials only after authentication and authorisation to join a call, not from an anonymous endpoint.

See the Secrets Management Guide.

Media servers: keys, fingerprints and resilience

ASVS 5.0 section V17.2 sets eight requirements for media servers. The ones most often missed in assessments are:

• DTLS key management (V17.2.1): the media server's DTLS certificate key is a cryptographic key like any other; it belongs in the documented key management process, with restricted file permissions or an HSM, and rotation.
• Cipher suites and SRTP profiles (V17.2.2): configure only approved DTLS cipher suites and a secure SRTP protection profile for DTLS-SRTP.
• SRTP authentication (V17.2.3): verify SRTP authentication at the media server so injected RTP cannot cause denial of service or insert audio or video.
• Malformed and flooded packets (V17.2.4, V17.2.5, V17.2.7): the media server, and any recording pipeline, must keep processing legitimate media when it receives malformed SRTP or a flood of packets from legitimate users.
• DTLS "ClientHello" race condition (V17.2.6, L3): confirm the media server is not vulnerable, by checking public advisories for the version in use or testing.
• Fingerprint check (V17.2.8, L3): verify the DTLS certificate against the SDP fingerprint attribute and terminate the stream if it does not match. Media servers that skip this check accept any DTLS peer.

Securing signalling

Signalling is ordinary web application security with real-time traffic patterns, plus one WebRTC-specific duty: it carries the fingerprints that the encryption depends on.

1. Transport: signalling only over TLS (wss:// and https://); the browser will not grant camera or microphone access to HTTP origins anyway.
2. Authentication: authenticate the WebSocket at connection time with a short-lived token, and validate the Origin header on the upgrade request, because browsers do not apply CORS to WebSockets.
3. Authorisation: check on every message that the sender is allowed in the room and allowed to perform the action (join, publish, mute others, start recording). Unguessable room IDs are not access control.
4. Integrity: never let one participant's message rewrite another participant's SDP; relay SDP unmodified or modify it only in server code you control, and log fingerprint changes mid-session.
5. Flood resilience (V17.3.1): rate limit at the signalling level per connection and per user so legitimate signalling continues during a flood.
6. Malformed input (V17.3.2): validate message size, type and structure, and handle integer overflows and parser errors without crashing the process.

Where SIP is used for signalling, the same controls apply; see the VoIP and SIP Security Guide for SIP-specific threats such as toll fraud and registration hijacking.

IP address exposure and privacy

ICE gathers candidate addresses so peers can find the best path, and those candidates can reveal more than users expect. RFC 8828 (Standards Track, January 2021) names the main concern: on a split-tunnel VPN, WebRTC can reveal the ISP-assigned public address alongside the VPN address. It also notes that private addresses behind NAT are a long-lived fingerprinting surface and can help attackers target intranet sites.

• Enterprises: RFC 8828 notes organisations can use firewall policy to force external WebRTC traffic through a TURN server or proxy while allowing direct internal connections. Managed browsers also expose policies to restrict WebRTC IP handling.
• Application design: applications that must hide user addresses from each other (marketplaces, anonymous support chat) should force relay-only ICE (iceTransportPolicy: "relay") so peers only ever see the TURN address.

Detection and measurement

Log TURN allocations (user ID from the credential, client address, requested peer address, bytes relayed, duration), refused peer addresses, authentication failures, signalling connection and room events, DTLS handshake failures and fingerprint mismatches. A refused peer address in the private range is never legitimate traffic from a normal client and deserves an alert.

• Relay exposure: number of successful relays to reserved address ranges (target zero, verified by a scheduled test).
• Credential hygiene: maximum TURN credential lifetime issued, and days since the shared secret was last rotated.
• Abuse indicators: top users by relayed bytes and allocations against their quota; allocations per user per hour.
• Integrity: DTLS fingerprint mismatches and handshake failures per thousand sessions.
• Resilience: call setup success rate and media server error rate during load and fuzz tests, measured per release.

Framework mapping

Common failure patterns

• TURN as an open internal proxy: no peer IP restrictions, so authenticated users relay to loopback, private ranges and cloud metadata, as in the Slack case reported by Enable Security.
• Long-lived or static TURN credentials in the client: a fixed username and password shipped in JavaScript turns the relay into free bandwidth for anyone who views the page source.
• Unlimited quotas: coturn quota and bandwidth settings default to unlimited, so one account can exhaust relay capacity for everyone.
• Signalling without per-message authorisation: users who know a room ID join calls or publish into rooms they were never invited to.
• Media server skips the fingerprint check: DTLS completes with any peer, undoing the binding between signalling and media.
• "End-to-end encrypted" claims for SFU calls: the media server decrypts every stream, and recordings sit in storage with broad access.

Practitioner checklist

• Map every WebRTC component (signalling, STUN, TURN, media servers, recording) with its owner, network placement and version.
• Block TURN relaying to all reserved IPv4 and IPv6 ranges in the TURN configuration and in network egress rules, and test it with valid credentials.
• Switch TURN to short-lived HMAC credentials issued after user authentication, with the shared secret in a secrets manager and a rotation schedule.
• Set per-user and total allocation quotas and bandwidth limits on TURN.
• Protect the media server DTLS key under your key management policy and enforce approved DTLS cipher suites and SRTP profiles.
• Confirm the media server verifies DTLS certificates against the SDP fingerprint and checks SRTP authentication.
• Authenticate WebSocket signalling, validate Origin, authorise every message and rate limit per user.
• Fuzz and load test signalling and media servers each release against ASVS V17.2 and V17.3.
• Choose an ICE policy (relay-only where user addresses must stay private) and an enterprise WebRTC IP handling policy.
• Alert on refused private-range peer addresses, fingerprint mismatches and quota exhaustion.

Standards and references

• OWASP: Application Security Verification Standard 5.0 (V17 WebRTC)
• IETF: RFC 8827 WebRTC Security Architecture
• IETF: RFC 8828 WebRTC IP Address Handling Requirements
• IETF: RFC 8656 Traversal Using Relays around NAT (TURN)
• coturn: Example turnserver.conf
• Enable Security: Slack WebRTC TURN compromise and bug bounty
• MITRE ATT&CK: Proxy
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: VoIP and SIP Security Guide · SSRF Prevention Guide · Secrets Management Guide · API Security Guide