Security Considerations for WebRTC
Extracted elements (25)
Consent to access local devices (camera/microphone) is orthogonal to consent to transmit network traffic. Device access consent protects user privacy from malicious sites; communications consent prevents the browser being used to attack its local network. Both must be enforced independently — WebSockets requires consent even without camera/microphone access.
Key continuity (analogous to SSH host key tracking) is far less useful in the WebRTC context because users routinely use multiple browsers on different computers with different keying material, causing frequent legitimate key changes. This trains users to click through mismatch warnings, and the calling service can trivially bypass the mechanism by presenting a slightly different peer name.
The RTCWEB WG ultimately required ICE rather than STUN-without-ICE or RTCP-based consent. RTCP-based consent allows a short window of attack and many legacy endpoints don't support RTCP. Standalone STUN checks cannot verify the recipient consents to this particular call, not just that they run a STUN endpoint.
WebRTC distinguishes two attacker classes: Web attackers who can induce users to visit their sites but do not control the network, and network attackers who can control network traffic. TLS/HTTPS prevent network injection attacks, but HTTP connections must be analyzed assuming traffic goes to the attacker.
ZRTP Short Authentication Strings (SAS) do not offer a practical solution against a compromised calling service because voice cloning systems can mimic a speaker's voice to forge SAS confirmation, and users are unlikely to voluntarily perform the SAS exchange. Additionally, key continuity after initial SAS verification is problematic for the reasons in Section 4.3.2.1.
Requiring ICE for consent verification limits compatibility with legacy non-ICE clients. Standalone STUN (without ICE credentials) cannot verify per-call consent. RTCP-based consent allows a short pre-consent attack window and is not supported by all legacy endpoints. An ICE-Lite implementation is effectively equivalent to a tightly integrated STUN approach, making ICE the preferred solution even for legacy scenarios.
A script from origin A MUST only be allowed to initiate communications (and hence to access the camera and microphone) if the user has specifically authorized access for that origin. The basic unit of Web sandboxing is the origin, so consent must be scoped to it.
For ICE consent verification, the receiving element MUST demonstrate receipt/knowledge of some value not available to the initiating site, preventing the site from forging responses. STUN transaction IDs MUST be generated by the browser and MUST NOT be made available to the initiating script, even via a diagnostic interface.
It MUST be possible for communicating parties to establish a channel secure against both message recovery and message modification, for both data and voice/video traffic. Technology such as SRTP, DTLS, and DTLS-SRTP provides this service.
It MUST NOT be possible for arbitrary sites to initiate calls to arbitrary locations without user consent. Allowing arbitrary sites to initiate calls would allow any malicious site to bug a user's computer without their knowledge.
The WebRTC system MUST NOT provide any APIs to extract long-term keying material or to directly access stored traffic keys. Such APIs would allow an attacker who subsequently compromised the calling service to recover traffic keys and decrypt recorded calls.
Until communications consent has been verified for a given endpoint, traffic other than the consent handshake MUST NOT be sent to that endpoint. This prevents using the browser as an attack platform against machines behind firewalls or NAT that would not otherwise be accessible.
WebRTC SHOULD use an automatic, public key-based key exchange mechanism providing Forward Secrecy. Using SDES-style key exchange where the calling service has access to traffic keying material is particularly dangerous because standard Web service logging practice makes it likely the key will be captured and subject to subsequent compromise.
ICE candidates expose the callee's server-reflexive IP address to the caller, revealing location information. Implementations may suppress ICE negotiation until call answer to avoid pre-answer tracking, and either side may route all traffic through TURN to hide their location. Sites can also use WebRTC to learn a user's real IP even when behind a VPN.
WebRTC API features add browser fingerprinting risk: sites can use the presence or absence of specific devices as a fingerprint. The API must be balanced between functionality and incremental fingerprint risk.
WebRTC provides persistent identifiers (DTLS certificates reused between connections, RTCP CNAMEs generated per RFC 6222) that can be used to correlate anonymous calls. Browsers must provide mechanisms to reset these identifiers, and the API should allow sites intended for anonymous calling to force fresh identifiers to be minted.
ICE (RFC 8445) provides the communications consent verification handshake required by WebRTC, serving double duty for NAT hole-punching and receiver consent. ICE uses STUN credentials as a per-session shared secret to verify the receiver wants to receive traffic from this particular sender at this time. RFC 7675 provides consent freshness via keepalives.
A compromised calling service can mount an undetectable MITM attack by telling Alice she is calling Bob and Bob he is calling Alice while acting as a calling bridge. Preventing this requires positive authentication of the remote endpoint via explicit out-of-band key verification or a third-party identity service as described in RFC 8827.
Cross-protocol attacks are a concern for WebRTC because an attacking script could generate traffic acceptable to a non-Web protocol state machine. WebSockets mitigates this with masking to randomize bits on the wire; for DTLS over WebRTC the risk is lower since ICE enforces consent, but SCTP over TCP carries some residual risk of attacker-controlled ciphertext.
If a calling service origin uses HTTP (not HTTPS), a network attacker on any unsecured network can inject an IFRAME or redirect to that origin, then forge the HTTP response to inject JavaScript initiating a call to themselves. The attacker can semi-permanently infect the origin via a Web worker, bugging the user long after leaving the infected network.
Peer identity authentication is necessary but not sufficient for media security: HTML5 MediaStreams can be manipulated by the calling site. A secure media mode is needed whereby sites can verifiably relinquish access to media streams, cryptographically binding the local media access policy into the authentication procedures, with both local and remote users able to verify engagement of this mode.
Screen sharing poses significantly greater security risks than camera/microphone access because it can violate the Same-Origin Policy invariant. An attacker site could request screen sharing, briefly open a window to the user's bank or webmail, and use the screen share to read displayed content including anti-CSRF tokens.
The core browser security guarantee — that users can safely visit arbitrary web sites including those hosting malicious scripts — defines the WebRTC threat model. Any new WebRTC functionality must be designed with the intent to meet this standard, treating the browser as a Trusted Computing Base.
Two distinct attack classes against WebRTC communications security must be distinguished: retrospective compromise (calling service was honest during the call but later compromised) and during-call attack (active MITM by the calling service). Forward secrecy protects against the former, but protecting against the latter is extremely difficult because the calling service controls both the signaling channel and the browser UI.
Web-based identity providers (OAuth, OpenID, BrowserID, etc.) can be used to authenticate WebRTC calls by binding the user's identity to cryptographic keying material used to authenticate calling endpoints. Calls authenticated in this fashion are naturally resistant even to active MITM attack by the calling site. PKI-style certificates also work for calls from end users to large sites.