RFC 8826

Security Considerations for WebRTC

📅 published January 2021, from ietf

Part 1 of 6 💖 more coming, bestie!

Security Considerations for WebRTC 🎀

Okay so this is RFC 8826 🦋, written by E. Rescorla at Mozilla. It's a Standards Track document, dated January 2021, with ISSN 2070-1721. Its header doesn't list any Obsoletes or Updates lines, so it doesn't replace or change any older RFCs. Its whole job is to lay out the WebRTC threat model and then analyze the security threats inside that model 🔥.

Abstract ✨

WebRTC is a protocol suite for real-time apps that can run in browsers, which is basically "real-time communication on the Web" 💜. This doc sets out the WebRTC threat model and goes through the security threats in that model.

Status of This Memo 📜

This one is an Internet Standards Track document, made by the IETF and reflecting IETF community consensus. It got public review and was approved by the Internet Engineering Steering Group (IESG) 💅. For more on Internet Standards, check Section 2 of RFC 7841. The current status, any errata, and how to send feedback live at https://www.rfc-editor.org/info/rfc8826 🌸.

Copyright Notice 💖

The legal bits, kept word for word so nobody gets confused 🙈:

Copyright (c) 2021 IETF Trust and the persons identified as the
document authors.  All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document.  Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.  Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008.  The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.

Table of Contents 🧚

1.  Introduction
2.  Terminology
3.  The Browser Threat Model
  3.1.  Access to Local Resources
  3.2.  Same-Origin Policy
  3.3.  Bypassing SOP: CORS, WebSockets, and Consent to Communicate
4.  Security for WebRTC Applications
  4.1.  Access to Local Devices
    4.1.1.  Threats from Screen Sharing
    4.1.2.  Calling Scenarios and User Expectations
      4.1.2.1.  Dedicated Calling Services
      4.1.2.2.  Calling the Site You're On
    4.1.3.  Origin-Based Security
    4.1.4.  Security Properties of the Calling Page
  4.2.  Communications Consent Verification
    4.2.1.  ICE
    4.2.2.  Masking
    4.2.3.  Backward Compatibility
    4.2.4.  IP Location Privacy
  4.3.  Communications Security
    4.3.1.  Protecting Against Retrospective Compromise
    4.3.2.  Protecting Against During-Call Attack
      4.3.2.1.  Key Continuity
      4.3.2.2.  Short Authentication Strings
      4.3.2.3.  Third-Party Identity
      4.3.2.4.  Page Access to Media
    4.3.3.  Malicious Peers
  4.4.  Privacy Considerations
    4.4.1.  Correlation of Anonymous Calls
    4.4.2.  Browser Fingerprinting
5.  Security Considerations
6.  IANA Considerations
7.  References
  7.1.  Normative References
  7.2.  Informative References
Acknowledgements
Author's Address

1. Introduction ✨

Okay so the Real-Time Communications on the Web (RTCWEB) Working Group standardized a bunch of protocols for real-time chat between browsers, usually called "WebRTC" [RFC8825] 🎀. The big use cases are real-time audio and/or video calls, web conferencing, and direct data transfer 📞. Here's the twist: unlike most real-time systems (like SIP-based [RFC3261] softphones), WebRTC calls are directly controlled by a web server 👑. Here's the simplest version:

                         +----------------+
                         |                |
                         |   Web Server   |
                         |                |
                         +----------------+
                             ^        ^
                            /          \
                   HTTPS   /            \   HTTPS
                     or   /              \   or
              WebSockets /                \ WebSockets
                        v                  v
                     JS API              JS API
               +-----------+            +-----------+
               |           |    Media   |           |
               |  Browser  |<---------->|  Browser  |
               |           |            |           |
               +-----------+            +-----------+
                   Alice                     Bob

                  Figure 1: A Simple WebRTC System

In that picture, Alice and Bob both have WebRTC-enabled browsers and they visit a web server that runs a calling service 🦋. Each browser has standardized JavaScript (JS) calling APIs built right in, and the web server uses those to set up a call between Alice and Bob 💅. The web server is also the signaling channel that carries control messages between the browsers 🫶. This is kind of like a conventional SIP-based system (where the web server is the signaling service and the browsers act as softphones), except control has moved to the central server, and the browser just provides the API hooks the calling service uses 🌈. And like any web app, the server can shuffle logic between itself and the JavaScript in the browser, but wherever the code runs, the server is still the one in charge 😭.

Okay, this setup brings new security problems that a regular Voice over IP (VoIP) system doesn't have 💀. The big one is malicious calling services. Say the calling service could make the browser call any callee it wants, at any time. That could be used to bug someone's computer without them knowing, just by calling some recording service 🙈. And if the exposed APIs let the server tell the browser to send arbitrary content, that could be used to get past firewalls or launch denial-of-service (DoS) attacks 🔥. So any system that works will have to hold up against this and other attacks 💪.

A companion document [RFC8827] describes a security architecture aimed at the issues raised here 🎀.

2. Terminology 💅

Here's the key-word rule, straight from the source. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🧠.

3. The Browser Threat Model 🧚

The security requirements for WebRTC come straight from the browser's main job, which is protecting the user 🛡️. Huang et al. [huang-w2sp] sum up the core browser security promise like this:

Users can safely visit arbitrary web sites and execute scripts provided by those sites.

This includes sites hosting arbitrary malicious scripts, and that's the point 😳. Attackers can easily send people to their sites, like buying display ads that lead users (automatically or by clicking) to their page, where the browser then runs the attacker's scripts 🙈. So it has to be safe to look at seriously malicious pages. Browsers do have bugs that keep them from fully hitting that goal, but any new WebRTC functionality must be designed with that standard in mind 🔥. The rest of this section gives more background on the existing Web security model 📚.

So in this model, the browser acts as a Trusted Computing Base (TCB), both from the user's point of view and, to some extent, from the server's 👑. HTML and JavaScript from the server can make the browser do lots of things, but those scripts run in a sandbox that keeps them separated from the user's computer and from each other, as explained below 🦋.

We usually talk about two kinds of attackers. Web attackers can trick you into visiting their sites but don't control the network. Network attackers can control your network 🌐. Network attackers match the [RFC3552] "Internet Threat Model". Also, a network attacker can be a Web attacker too, since transport protocols without integrity protection let the network inject traffic as if it were any communications peer 😬. TLS, and HTTPS in particular, guards against these attacks, but when we analyze HTTP connections, we have to assume the traffic is going to the attacker 🫣.

3.1. Access to Local Resources 🎀

The browser can reach local resources like keying material, files, the camera, and the microphone, but it strictly limits or forbids web servers from touching those same resources 🔒. For example, you can build an HTML form that allows file upload, but a script can't do that without user consent, and it can't even suggest a specific file (like /etc/passwd). The user has to pick the file and agree to upload it 📂. (Note: browsers are often deliberately designed to avoid dialogs with the meaning of "click here to bypass security checks", because extensive research [cranor-wolf] shows users tend to consent in those situations 🙈.)

Flash programs (SWFs) [SWF] can access the camera and microphone too, but they explicitly require the user's consent for that access 📸. Some resources just can't be reached from the browser at all. For example, there's no real way to run specific executables directly from a script, though the user can of course be tricked into downloading executable files and running them 💀.

…to be continued in Part 2 🫶

3.2. Same-Origin Policy ✨

Okay so, plenty of other resources are reachable but kept isolated, bestie 🦋. Scripts are allowed to make HTTP requests with the fetch() API (see [fetch]) when the request goes to a server that is not the same origin the script came from [RFC6454]. The catch? They are NOT able to read the responses 🙈. Cross-Origin Resource Sharing (CORS) [fetch] and WebSockets [RFC6455] are the escape hatches from this restriction, and we'll get into them below. This same-origin policy (SOP) is what stops server A from launching attacks on server B through the user's browser 💅. It protects the user (say, from having their credentials misused) and it protects server B (say, from DoS attacks) 💜.

Zooming out, SOP basically forces scripts from each site to run in their own isolated sandboxes 🧚. There are techniques that let them talk to each other, but those interactions generally have to be mutually consensual (agreed to by each site) and they're limited to certain channels 🎀. For example, multiple pages or browser panes from the same origin can read each other's JS variables, but pages from different origins can't, and that's true even for IFRAMEs from different origins sitting on the same page 🚫. Iconic boundaries, honestly 👑.

3.3. Bypassing SOP: CORS, WebSockets, and Consent to Communicate 🔓

SOP is super important for security, but ngl it makes certain kinds of apps really annoying to build 😭. Mash-ups are the big example: that's when a script from origin A uses resources from origin B, and you can only pull that off with a whole lot of hackery 💀. The W3C CORS spec [fetch] is basically the answer to that demand 🌈. With CORS, when a script from origin A makes a potentially unsafe cross-origin request, the browser instead checks with the target server to see whether it's willing to allow cross-origin requests from A 🫶. If the server says yes, the browser lets the request through ✨. This consent verification process is designed to make cross-origin requests safe 💖.

CORS is for cross-origin HTTP requests, but WebSockets [RFC6455] is all about allowing cross-origin establishment of transparent channels 🦋. Once a WebSockets connection is set up from a script to a site, the script can send whatever traffic it likes 🔥. It doesn't have to wrap everything up as a series of HTTP request/response transactions 🌸. Just like CORS, a WebSockets transaction kicks off with a consent verification stage, so scripts can't just blast arbitrary data at some other origin 🙅‍♀️.

Consent verification sounds simple in theory (just do a handshake before you start sending the real data 🤝), but experience has shown that designing a correct one is genuinely hard 😩. Huang et al. [huang-w2sp] showed vulnerabilities in the existing Java and Flash consent verification techniques, and also in a simplified version of the WebSockets handshake 💀. You have to be wary of CROSS-PROTOCOL attacks, where the attacking script generates traffic that some non-Web protocol state machine will accept as valid 👀. To resist this, WebSockets uses a masking technique meant to randomize the bits on the wire, which makes it harder to craft traffic that looks like a given protocol 🎀. Genius, periodt 👑.

Security for WebRTC Applications 🎀

4.1. Access to Local Devices 📹

As we covered in Section 1, letting arbitrary sites start calls breaks the core Web security guarantee 😱. Without some access restrictions on local devices, any malicious site could literally bug a user 🙈. So at minimum, it MUST NOT be possible for arbitrary sites to initiate calls to arbitrary locations without user consent 🛑. That raises the big question of what the scope of user consent should actually be 🤔.

For the user to make an intelligent decision about whether to allow a call (and therefore have their camera and microphone input routed somewhere), they need to understand who is requesting access, where the media is going, or both 🧠. There are two basic conceptual models:

You are sending your media to entity A because you want to talk to entity A (e.g., your mother) 💕.
Entity A (e.g., a calling service) asks to access the user's devices with the assurance that it will transfer the media to entity B (e.g., your mother) 📞.

In either case, identity is at the heart of any consent decision 💖. Also, the identity of the party the browser is connecting to is all the browser can meaningfully enforce 😤. If you're calling A, A can just forward the media to C 💀. Likewise, if you authorize A to place a call to B, A can call C instead 🙃. Either way, all the browser can do is verify and check authorization for whoever is controlling where the media goes 🔍. The target of the media can of course advertise a security/privacy policy, but the browser can't enforce that 🫠. Even so, there are a variety of different consent scenarios, and each one motivates different technical consent mechanisms 🌈. We'll discuss those mechanisms in the sections below 👇.

It's important to get that consent to access local devices is largely orthogonal to consent to transmit various kinds of data over the network (see Section 4.2) 🧩. Consent for device access is mostly about protecting the user's privacy from malicious sites 🔒. Consent to send network traffic, on the other hand, is about stopping the user's browser from being used to attack its local network 🚨. So we need communications consent even if the site can't access the camera and microphone at all (hence WebSockets's consent mechanism) 🧦. And we also have to worry about the site accessing the user's camera and microphone even when the data is going back to the site through conventional HTTP-based network mechanisms, like HTTP POST 📮.

4.1.1. Threats from Screen Sharing 🖥️

Besides camera and microphone access, people have been asking for screen and/or application sharing 🙌. The security implications are way harder for users to intuitively analyze than camera and microphone access 😵‍💫. (For a full breakdown, see <https://lists.w3.org/Archives/Public/public-webrtc/2013Mar/0024.html> 📚.)

The most obvious threats are just "oversharing" 🫣. The user might think they're sharing one window when they're actually sharing an entire application, or they might forget they're sharing their whole screen, icons, notifications, and all 😬. This already happens with existing screen sharing tech, and it gets somewhat worse if a partially trusted site is the one asking for the resource to be shared instead of the user proposing it 💅.

A less obvious threat is how screen sharing affects the Web security model 🧐. A key part of the Same-Origin Policy is that HTML or JS from site A can reference content from site B and make the browser load it, but (unless explicitly permitted) it cannot see the result 👀. If a Web application from a site is screen sharing the browser, though, that invariant is broken, with serious security consequences 🚨. For example, an attacker site could request screen sharing, then briefly open a new window to the user's bank or webmail account and use screen sharing to read the displayed content 💸. A more sophisticated attack would open a source view window to a site and use the screen sharing result to view anti-cross-site request forgery tokens 😈.

These threats suggest that screen/application sharing might need a higher level of user consent than access to the camera or microphone 🔐.

4.1.2. Calling Scenarios and User Expectations 📱

A large number of calling scenarios are possible, but the ones discussed in this section show a lot of the difficulties in figuring out the relevant scope of consent 🧩.

4.1.2.1. Dedicated Calling Services 📞

The first scenario is a dedicated calling service 💜. Here, the user has a relationship with a calling site and makes calls on it again and again 🔁. It's likely the user won't want to give permission for each call, so they'll probably want to give the calling service long-term access to the camera and microphone 🎥. That's a natural fit for a long-term consent mechanism (e.g., installing an app store "application" to indicate permission for the calling service) 📲. A variant of this is a gaming site (e.g., a poker site) that hosts a dedicated calling service so players can call each other 🃏.

With any service where the user might use the same one to talk to lots of different people, there's a question of whether the user can know who they're talking to 🤷‍♀️. If I grant calling service A permission to make calls on my behalf, I'm implicitly granting it permission to bug my computer whenever it wants 😭. That suggests another consent model, where a site is authorized to make calls but only to certain target entities (identified via media-plane cryptographic mechanisms as described in Section 4.3.2 and especially Section 4.3.2.3) 🔐. Note that consent here is related to, but distinct from, the question of peer identity 💡. I might be willing to let a calling site start calls on my behalf in general, but still have some calls through that site where I can be sure the site isn't listening in 🫣.

4.1.2.2. Calling the Site You're On 🛍️

Another simple scenario is calling the site you're actually visiting 📣. The classic example is the "click here to talk to a representative" window that pops up on tons of shopping sites 💁‍♀️. In this case, the user expects to be calling the site they're on 🙋‍♀️. But they probably don't want to give general consent to that site 🙅‍♀️. Just because I want some info on a car doesn't mean I want the car manufacturer to be able to turn on my microphone whenever they like 🚗💥. So this calls for a second consent mechanism, where I only grant consent for the duration of a given call ⏱️. As described in Section 3.1, great care must be taken in designing this interface so users don't just click through it 🖱️. Also, the user interface chrome (the part of the UI the user interacts with through the user agent itself) MUST clearly display elements showing the call is continuing 🪟, so attacks can't leave the call running indefinitely while showing a Web UI that suggests otherwise 🕵️‍♀️.

4.1.3. Origin-Based Security 🔐✨

okay so now that we've gone through the calling scenarios, it's time to think about the security requirements 💅

Remember from Section 3.2? The origin is the basic unit of Web sandboxing, so it's totally natural to scope consent to the origin 🧚. Specifically, 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. Coarser-scoped permissions are technically possible 🙃, but because the Web model is scoped to the origin, it creates a seriously awkward mismatch 💀.

Arguably, the origin isn't fine-grained enough 🫠. Say Alice visits a site and authorizes it to make a single call. If consent is expressed only in terms of the origin, then on any future visit to that site (including one induced via a mash-up or ad network), the site can bug Alice's computer, use the computer to place bogus calls, etc. 😱 Sure, in principle Alice could grant and then revoke the privilege, but in practice privileges accumulate. So if we're worried about this attack, something else is needed. There are a number of potential countermeasures to this sort of issue 🌸.

Individual Consent: Ask the user for permission for each call.
Callee-oriented Consent: Only allow calls to a given user.
Cryptographic Consent: Only allow calls to a given set of peer keying material or to a cryptographically established identity.

Unfortunately, none of these approaches is satisfying for every case 😩. Individual consent puts the user's approval in the UI flow for every single call. Not only does that get annoying fast, it can also train the user to just click "OK" on autopilot, and then the consent is useless 🙄. So while individual consent may be necessary in some cases, it's not a suitable solution for (for instance) the calling service case. Where it is necessary, in-flow user interfaces must be carefully designed to avoid the risk of the user blindly clicking through 👀.

The other two options are designed to restrict calls to a given target. Callee-oriented consent provided by the calling site wouldn't work well, because a malicious site can claim that the user is calling any user of their choice 😤. One fix is to tie calls to a cryptographically established identity. That's not suitable for all cases, but it may be useful for some 🔑. Think about advertising: it's not particularly convenient to make the advertiser instantiate an IFRAME on the hosting site just to get permission. A more convenient approach is to cryptographically tie the advertiser's certificate to the communication directly 📜. We're still tying permissions to an origin here, but to the media origin (and/or destination) rather than the Web origin 🎯. [RFC8827] describes mechanisms which facilitate this sort of consent 🦋.

Another case where media-level cryptographic identity makes sense is when a user really doesn't trust the calling site. For instance, I might be worried that the calling service will try to bug my computer, but I also still want to be able to conveniently call my friends 📞💖. If consent is tied to particular communications endpoints, my risk is limited 🛡️. Naturally, it's kind of tricky to design UI primitives that express this sort of policy 🥲. The problem gets even more challenging in multi-user calling cases 🌀.

4.1.4. Security Properties of the Calling Page 🕵️‍♀️

Origin-based security is meant to protect against Web attackers. But we also have to think about network attackers 👾. Say I've granted permission to a calling service from an origin that uses the HTTP scheme, e.g., http://calling-service.example.com. If I ever use my computer on an unsecured network (like a hotspot, or if my own home wireless network is insecure) and browse any HTTP site, then an attacker can bug my computer 😭. The attack goes like this:

I connect to http://anything.example.org/. Note that this site is unaffiliated with the calling service 🙈.
The attacker modifies my HTTP connection to inject an IFRAME (or a redirect) to http://calling-service.example.com.
The attacker forges the response from http://calling-service.example.com/ to inject JS that initiates a call to themselves 💀.

Note that this attack doesn't depend on the media being insecure. Because the call is to the attacker, it's also encrypted to them 🔒. And it doesn't have to run right away! The attacker can "infect" the origin semi-permanently (for example, with a Web worker, or a popped-up window hidden under the main window) and then bug me long after I've left the infected network 🧟. This risk exists because calls are allowed at all from a page fetched over HTTP 🚨.

Even if calls are only possible from HTTPS [RFC2818] sites, if those sites include active content (e.g., JavaScript) from an untrusted site, that JavaScript runs in the security context of the page [finer-grained] 😬. This could lead to compromise of a call even if the parent page is safe 🫣. Note: This issue isn't limited to pages that contain untrusted content. If any page from a given origin ever loads JavaScript from an attacker, then that attacker can infect the browser's notion of that origin semi-permanently 🧃🦠.

As discussed in Section 3.3, letting Web applications have unrestricted network access via the browser opens the door to using the browser as an attack platform against machines that the malicious site couldn't otherwise reach. For example, those machines might be topologically restricted (e.g., behind a firewall or NAT) 🧱. To prevent this form of attack, as well as cross-protocol attacks, it's important to require that the target of traffic explicitly consent to receiving that traffic 🙋‍♀️. Until that consent has been verified for a given endpoint, traffic other than the consent handshake MUST NOT be sent to that endpoint 🚫.

Consent verification isn't enough to prevent overuse of network resources though 😮‍💨. Because WebRTC lets a Web site create data flows between two browser instances without user consent, a malicious site could chew up a ton of a user's bandwidth while spending basically nothing itself, just by setting up such a channel to another user 📉. As a practical matter, though, there are loads of Web sites that can act as data sources, so an attacker can at least use downlink bandwidth with existing Web APIs 📥. This potential DoS vector is why WebRTC protocols need adequate congestion control, so they play fair with other demands on the user's bandwidth 🤹‍♀️.

4.2.1. ICE 🧊

Verifying receiver consent requires some sort of explicit handshake, but conveniently we already need one for NAT hole-punching 🕳️✨. Interactive Connectivity Establishment (ICE) [RFC8445] includes a handshake designed to verify that the receiving element wants to receive traffic from the sender 🤙. Remember that the site initiating ICE is presumed malicious 😈. For the handshake to be secure, the receiving element MUST demonstrate receipt/knowledge of some value not available to the site (which stops the site from forging responses) 🔐. To achieve this with ICE, the Session Traversal Utilities for NAT (STUN) transaction IDs must be generated by the browser, and they MUST NOT be made available to the initiating script, even via a diagnostic interface 🙅‍♀️.

Verifying receiver consent also means verifying that the receiver wants to receive traffic from a particular sender, and at this time 🕰️. For example, a malicious site may simply attempt ICE to known servers that are using ICE for other sessions 👀. ICE handles this too, by using the STUN credentials as a form of per-session shared secret 🗝️. Those credentials are known to the Web application, but they'd also need to be known and used by the STUN-receiving element to be useful 💅.

There also needs to be some mechanism for the browser to verify that the target of the traffic still wants to receive it 🔄. Because ICE keepalives are indications, they won't work here 🙅. [RFC7675] describes the mechanism for providing consent freshness 🌈.

4.2.2. Masking 🎭

Once consent is verified, there's still some concern about misinterpretation attacks, as described by Huang et al. [huang-w2sp] 🕵️. This doesn't seem like a serious concern with DTLS, because the ICE handshake enforces receiver consent and there's little evidence of passive DTLS proxies of the type Huang studied 👍. However, because RTCWEB can run over TCP, there's some concern that attackers might control the ciphertext by controlling the plaintext input to SCTP 😰. This risk is only partially mitigated by the fact that the SCTP stack controls the framing of the packets 📦.

Note that in principle an attacker could exert some control over Secure Real-time Transport Protocol (SRTP) packets by combining the WebAudio API with extremely tight timing control 🎧⏱️. The main risk here seems to be SRTP carried over Traversal Using Relays around NAT (TURN) TCP 🧵. But SRTP packets have an extremely characteristic packet header, so it seems unlikely that any but the most aggressive intermediaries would be confused into thinking another application-layer protocol was in use 🫶💜.

4.2.3. Backward Compatibility 🎀

📣 Note: The RTCWEB WG ultimately decided to require ICE. This section provides context for that decision.

okay so, requiring ICE means legacy non-ICE clients get left out 💀 but it still feels unsafe to just yeet the requirement for some check, bestie. 😭

Every proposed check works the same way: the browser sends some message to the candidate traffic recipient and refuses to send any other traffic until that message gets a reply. The message/reply pair has to be built so that an attacker who controls the Web application can't forge them. Usually that means the message carries some secret value that has to be incorporated somehow (e.g., echoed, hashed into, etc.). ✨ Non-ICE candidates for this role (in cases where the legacy endpoint has a public address) include:

STUN checks without using ICE (i.e., the non-RTC-web endpoint sets up a STUN responder).
Use of the RTP Control Protocol (RTCP) as an implicit reachability check.

In the RTCP approach, the WebRTC endpoint is allowed to send a limited number of RTP packets before it gets consent. 🫣 That leaves a short window of attack. Also, some legacy endpoints don't support RTCP, so this is a way more expensive solution for them, and it would probably be easier to just implement ICE. For these two reasons, an RTCP-based approach doesn't seem to address the security issue satisfactorily. 🙅‍♀️

In the STUN approach, the WebRTC endpoint can verify that the recipient is running some kind of STUN endpoint. BUT unless the STUN responder is integrated with the ICE username/password establishment system, the WebRTC endpoint can't verify that the recipient consents to this particular call. That could be a problem if existing STUN servers live at addresses that can't handle bandwidth-based attacks. So this approach doesn't seem satisfactory either. 💅

If the systems are tightly integrated (i.e., the STUN endpoint responds with responses authenticated with ICE credentials), then this issue doesn't exist. Hmm, but honestly? Such a design is very close to an ICE-Lite implementation (indeed, arguably is one). 🤭 An intermediate approach would be a STUN extension that indicated one was responding to WebRTC checks but was not computing integrity checks based on the ICE credentials. This would let people use standalone STUN servers without the risk of confusing them with legacy STUN servers. If a non-ICE legacy solution is needed, this is probably the best choice. 🌸

Once initial consent is verified, we also need to verify continuing consent. 👀 The reason: attacks where two people briefly share an IP (e.g., behind a NAT in an Internet cafe), and the attacker sets up a large, unstoppable traffic flow to the network and then leaves. The appropriate technologies here are fairly similar to the ones for initial consent, though they're perhaps weaker since the threats are less severe. 🧚

4.2.4. IP Location Privacy 🦋

Heads up, bestie: as soon as the callee sends their ICE candidates, the caller learns the callee's IP addresses. 😳 The callee's server-reflexive address reveals a lot about where they are. To avoid tracking, implementations may wish to suppress the start of ICE negotiation until the callee has answered. Also, either side may wish to hide their location from the other side entirely by forcing all traffic through a TURN server. 🫶

In ordinary operation, the site learns the browser's IP address, though it can be hidden with stuff like Tor, <https://www.torproject.org>, or a VPN. BUT here's the tea: because sites can make the browser provide IP addresses, sites can still learn about the user's network environment even when the user is behind a VPN that masks their IP address. 👁️ Implementations may wish to offer settings that suppress all non-VPN candidates if the user is on certain kinds of VPN, especially privacy-oriented systems like Tor. See [RFC8828] for additional information. 🔒

4.3. Communications Security 💜

Finally, we get to a problem familiar from the SIP world: communications security. 🔐 For obvious reasons, it MUST be possible for the communicating parties to establish a channel that's secure against both message recovery and message modification. (See [RFC5479] for more details.) This service must be provided for both data and voice/video. Ideally the same security mechanisms would be used for both types of content. The technology for providing this service (for instance, SRTP [RFC3711], DTLS [RFC6347], and DTLS-SRTP [RFC5763]) is well understood. However, we have to examine this technology in the WebRTC context, where the threat model is somewhat different. 🕵️‍♀️

Okay, the big difference: unlike a conventional SIP proxy, the calling service (i.e., the Web server) controls not only the channel between the communicating endpoints but also the application running on the user's browser. 😤 In principle, the browser could cut the calling service out of the loop and directly present trusted information (and maybe get consent), but in practice modern browsers avoid this whenever possible. "In-flow" modal dialogs that make the user consent to specific actions are especially disfavored, because human factors research shows that unless they're made extremely invasive, users just agree to them without actually consciously giving consent [abarth-rtcweb]. So nearly all the UI will necessarily be rendered by the browser but under control of the calling service. This likely includes the peer's identity information, which, after all, is only meaningful in the context of some calling service. 🫠

This limitation doesn't mean preventing attacks by the calling service is completely hopeless. 🙌 However, we need to split attacks into two classes:

Retrospective compromise of calling service: The calling service is non-malicious during a call but gets compromised afterwards and wants to attack an older call (often called a "passive attack"). 🕰️

During-call attack by calling service: The calling service gets compromised during the call it wants to attack (often called an "active attack"). 🚨

Protecting against the former type of attack is practical using the techniques discussed in Section 4.3.1. ✅ However, it's extremely difficult to stop a trusted but malicious calling service from actively attacking a user's calls, either by mounting a Man-in-the-Middle (MITM) attack or by diverting them entirely. (Note that this attack applies equally to a network attacker if communications to the calling service aren't secured.) We discuss some potential approaches in Section 4.3.2. 🧩

4.3.1. Protecting Against Retrospective Compromise 🗝️

In a retrospective attack, the calling service was uncompromised during the call, but an attacker afterwards wants to recover the content of the call. We assume the attacker has access to the protected media stream as well as full control of the calling service. 😈

If the calling service has access to the traffic keying material (as in Security Descriptions (SDES) [RFC4568]), then retrospective attack is trivial. 💀 This is especially serious in the Web context, because it's standard practice in Web services to run extensive logging and monitoring. So if the traffic key is part of any HTTP request, it's highly likely to get logged somewhere and therefore be subject to later compromise. 📝 This is why an automatic, public key-based key exchange mechanism is imperative for WebRTC (it's a good idea for any communications security system, tbh), and this mechanism SHOULD provide Forward Secrecy (FS). The signaling channel/calling service can be used to authenticate this mechanism. 🔑

Also, if end-to-end keying is used, the system MUST NOT provide any APIs to either extract long-term keying material or to directly access any stored traffic keys. ⛔ Otherwise, an attacker who later compromised the calling service might be able to use those APIs to recover the traffic keys and thus compromise the traffic. 😱

4.3.2. Protecting Against During-Call Attack 🚧

Protecting against attacks during a call is a much harder ask. 😮‍💨 Even if the calling service can't directly access keying material (as recommended in the previous section), it can still mount a man-in-the-middle attack on the connection. It tells Alice she's calling Bob and tells Bob he's calling Alice, while the calling service is actually acting as a calling bridge and capturing all the traffic. 🙃 Protecting against this form of attack requires positive authentication of the remote endpoint, such as explicit out-of-band key verification (e.g., by a fingerprint) or a third-party identity service as described in [RFC8827]. 🪪

4.3.2.1. Key Continuity 🔁

One natural approach is "key continuity." ✨ While a malicious calling service can present any identity it chooses to the user, it can't produce a private key that maps to a given public key. So the browser can note a given user's public key and generate an alarm whenever that user's key changes. The Secure Shell (SSH) protocol [RFC4251] uses a similar technique. (Note that the need to avoid explicit user consent on every call rules out the browser requiring an immediate manual check of the peer's key. 🙅‍♀️)

Unfortunately, this sort of key continuity mechanism is way less useful in the WebRTC context. 🥲 First, a huge part of the appeal of WebRTC (and any Web application) is that it isn't tied to a particular piece of client software. So it's not only possible but routine for a user to use multiple browsers on different computers, which will of course have different keying material (Securely Available Credentials (SACRED) [RFC3760] notwithstanding). As a result, users will frequently get alerted to key mismatches that are totally legitimate, and they'll get trained to just click through them. 🖱️ Since it's known that users routinely click through far more dire warnings [cranor-wolf], it seems extremely unlikely that any key continuity mechanism will be effective rather than simply annoying. 😩

Moreover, it's trivial to bypass even this kind of mechanism. 🫣 Remember, unlike the case of SSH, the browser never directly gets the peer's identity from the user. Instead, it's provided by the calling service. Even enabling a mechanism of this type would require an API that lets the calling service tell the browser "this is a call to user X." All the calling service needs to do to avoid triggering a key continuity warning is tell the browser "this is a call to user Y," where Y is confusable with X. 🎭 Even if the user actually checks the other side's name (which all available evidence says is unlikely), that would require (a) the browser to use the trusted UI to provide the name and (b) the user to not be fooled by similar-looking names. 👀

4.3.2.2. Short Authentication Strings ✨

okay so ZRTP [RFC6189] has this thing called a "Short Authentication String" (SAS) 🔐 that gets derived from the key agreement protocol. The SAS is designed to be compared by the users (e.g., read aloud over the voice channel or transmitted via an out-of-band channel), and if both sides confirm it, it precludes MITM attack 🙅‍♀️. The intention is that the SAS is used once, and then key continuity (though with a different mechanism from that discussed above) is used thereafter 💖.

Unfortunately, the SAS does not offer a practical solution to the problem of a compromised calling service 😭. "Voice cloning" systems, which mimic the voice of a given speaker, are an active area of research [deepfakes-ftc] and are already being used in real-world attacks [deepfakes-fraud] 💀. These attacks are likely to improve in future, especially in an environment where the user just wants to get on with the phone call. Thus, even if the SAS is effective today, it is likely not to be so for much longer 🥀.

Additionally, it is unclear that users will actually use an SAS 🙈. As discussed above, the browser UI constraints preclude requiring the SAS exchange prior to completing the call, and so it must be voluntary; at most the browser will provide some UI indicator that the SAS has not yet been checked. However, it is well known that when faced with optional security mechanisms, many users simply ignore them [whitten-johnny] 🙃.

Once users have checked the SAS once, key continuity is required to avoid them needing to check it on every call. However, this is problematic for reasons indicated in Section 4.3.2.1 💅. In principle it is of course possible to render a different UI element to indicate that calls are using an unauthenticated set of keying material (recall that the attacker can just present a slightly different name so that the attack shows the same UI as a call to a new device or to someone you haven't called before), but as a practical matter, users simply ignore such indicators even in the rather more dire case of mixed content warnings 🚩.

4.3.2.3. Third-Party Identity 🪪

okay so the conventional approach to providing communications identity has of course been to have some third-party identity system (e.g., PKI) to authenticate the endpoints. Such mechanisms have proven to be too cumbersome for use by typical users (and nearly too cumbersome for administrators) 😩. However, a new generation of Web-based identity providers (BrowserID, Federated Google Login, Facebook Connect, OAuth [RFC6749], OpenID [OpenID], WebFinger [RFC7033]) has been developed and uses Web technologies to provide lightweight (from the user's perspective) third-party authenticated transactions ✨. It is possible to use systems of this type to authenticate WebRTC calls, linking them to existing user notions of identity (e.g., Facebook adjacencies). Specifically, the third-party identity system is used to bind the user's identity to cryptographic keying material, which is then used to authenticate the calling endpoints. Calls which are authenticated in this fashion are naturally resistant even to active MITM attack by the calling site 🛡️.

Note that there is one special case in which PKI-style certificates do provide a practical solution: calls from end users to large sites. For instance, if you are making a call to Amazon.com, then Amazon can easily get a certificate to authenticate their media traffic, just as they get one to authenticate their Web traffic 📦. This does not provide additional security value in cases in which the calling site and the media peer are one and the same, but it might be useful in cases in which third parties (e.g., ad networks or retailers) arrange for calls but do not participate in them 🎀.

4.3.2.4. Page Access to Media 👀

identifying the identity of the far media endpoint is a necessary but not sufficient condition for providing media security 🧐. In WebRTC, media flows are rendered into HTML5 MediaStreams, which can be manipulated by the calling site. Obviously, if the site can modify or view the media, then the user is not getting the level of assurance they would expect from being able to authenticate their peer 😬. In many cases this is acceptable, because the user values site-based special effects over complete security from the site 🌈. However, there are also cases where users wish to know that the site cannot interfere. In order to facilitate that, it will be necessary to provide features whereby the site can verifiably give up access to the media streams. This verification must be possible both from the local side and the remote side. I.e., users must be able to verify that the person called has engaged a secure media mode (see Section 4.3.3). In order to achieve this, it will be necessary to cryptographically bind an indication of the local media access policy into the cryptographic authentication procedures detailed in the previous sections 🔗.

It should be noted that the use of this secure media mode is left to the discretion of the site. When such a mode is engaged, the browser will need to provide indicia to the user that the associated media has been authenticated as coming from the identified user. This allows WebRTC services that wish to claim end-to-end security to do so in a way that can be easily verified by the user 🫶. This model requires that the remote party's browser be included in the TCB, as described in Section 3.

4.3.3. Malicious Peers 🎭

One class of attack that we do not generally try to prevent is malicious peers. For instance, no matter what confidentiality measures you employ, the person you are talking to might record the call and publish it on the Internet 📼. Similarly, we do not attempt to prevent them from using voice or video processing technology for hiding or changing their appearance. While technologies (Digital Rights Management (DRM), etc.) do exist to attempt to address these issues, they are generally not compatible with open systems, and WebRTC does not address them 🙅‍♀️.

Similarly, we make no attempt to prevent prank calling or other unwanted calls. In general, this is in the scope of the calling site, though because WebRTC does offer some forms of strong authentication, that may be useful as part of a defense against such attacks 📞.

4.4. Privacy Considerations 🤫

4.4.1. Correlation of Anonymous Calls 🕵️‍♀️

While persistent endpoint identifiers can be a useful security feature (see Section 4.3.2.1), they can also represent a privacy threat in settings where the user wishes to be anonymous 🥷. WebRTC provides a number of possible persistent identifiers, such as DTLS certificates (if they are reused between connections) and RTCP CNAMEs (if generated according to [RFC6222] rather than the privacy-preserving mode of [RFC7022]). In order to prevent this type of correlation, browsers need to provide mechanisms to reset these identifiers (e.g., with the same lifetime as cookies) 🍪. Moreover, the API should provide mechanisms to allow sites intended for anonymous calling to force the minting of fresh identifiers. In addition, IP addresses can be a source of call linkage [RFC8828] 📍.

4.4.2. Browser Fingerprinting 🫆

Any new set of API features adds a risk of browser fingerprinting, and WebRTC is no exception 🥲. Specifically, sites can use the presence or absence of specific devices as a browser fingerprint. In general, the API needs to be balanced between functionality and the incremental fingerprint risk. See [Fingerprinting].

5. Security Considerations 🔐💀

This entire document is about security. Full stop, no exceptions, we are not being dramatic at all 😤🔥.

6. IANA Considerations 📋

This document has no IANA actions 🌸.

7. References 📚

7.1. Normative References

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

7.2. Informative References 📚

okay bestie, this is the reading list 🦋 these are the extra sources the RFC points to for background. they aren't required to implement the spec, but they're the receipts behind the security takes 💅

[abarth-rtcweb]: Barth, A., "Prompting the user is security failure", RTC-Web Workshop, September 2010, http://rtc-web.alvestrand.com/home/papers/barth-security-prompt.pdf?attredirects=0.

[cranor-wolf]: Sunshine, J., Egelman, S., Almuhimedi, H., Atri, N., and L. Cranor, "Crying Wolf: An Empirical Study of SSL Warning Effectiveness", Proceedings of the 18th USENIX Security Symposium, August 2009, https://www.usenix.org/legacy/event/sec09/tech/full_papers/sunshine.pdf.

[deepfakes-fraud]: Statt, N., "Thieves are now using AI deepfakes to trick companies into sending them money", September 2019, https://www.theverge.com/2019/9/5/20851248/deepfakes-ai-fake-audio-phone-calls-thieves-trick-companies-stealing-money.

[deepfakes-ftc]: Lyons, K., "FTC says the tech behind audio deepfakes is getting better", January 2020, https://www.theverge.com/2020/1/29/21080553/ftc-deepfakes-audio-cloning-joe-rogan-phone-scams.

[fetch]: van Kesteren, A., "Fetch", https://fetch.spec.whatwg.org/.

[finer-grained]: Jackson, C. and A. Barth, "Beware of Finer-Grained Origins", Web 2.0 Security and Privacy (W2SP 2008), July 2008.

[Fingerprinting]: Doty, N., Ed., "Mitigating Browser Fingerprinting in Web Specifications", March 2019, https://www.w3.org/TR/fingerprinting-guidance/.

[huang-w2sp]: Huang, L-S., Chen, E.Y., Barth, A., Rescorla, E., and C. Jackson, "Talking to Yourself for Fun and Profit", Web 2.0 Security and Privacy (W2SP 2011), May 2011.

[OpenID]: Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and C. Mortimore, "OpenID Connect Core 1.0", November 2014, https://openid.net/specs/openid-connect-core-1_0.html.

[RFC2818]: Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, https://www.rfc-editor.org/info/rfc2818.

[RFC3261]: Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, https://www.rfc-editor.org/info/rfc3261.

[RFC3552]: Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, https://www.rfc-editor.org/info/rfc3552.

[RFC3711]: Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, https://www.rfc-editor.org/info/rfc3711.

[RFC3760]: Gustafson, D., Just, M., and M. Nystrom, "Securely Available Credentials (SACRED) - Credential Server Framework", RFC 3760, DOI 10.17487/RFC3760, April 2004, https://www.rfc-editor.org/info/rfc3760.

[RFC4251]: Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, January 2006, https://www.rfc-editor.org/info/rfc4251.

[RFC4568]: Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, https://www.rfc-editor.org/info/rfc4568.

[RFC5479]: Wing, D., Ed., Fries, S., Tschofenig, H., and F. Audet, "Requirements and Analysis of Media Security Management Protocols", RFC 5479, DOI 10.17487/RFC5479, April 2009, https://www.rfc-editor.org/info/rfc5479.

[RFC5763]: Fischl, J., Tschofenig, H., and E. Rescorla, "Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 2010, https://www.rfc-editor.org/info/rfc5763.

[RFC6189]: Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP: Media Path Key Agreement for Unicast Secure RTP", RFC 6189, DOI 10.17487/RFC6189, April 2011, https://www.rfc-editor.org/info/rfc6189.

[RFC6222]: Begen, A., Perkins, C., and D. Wing, "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)", RFC 6222, DOI 10.17487/RFC6222, April 2011, https://www.rfc-editor.org/info/rfc6222.

[RFC6347]: Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, https://www.rfc-editor.org/info/rfc6347.

[RFC6454]: Barth, A., "The Web Origin Concept", RFC 6454, DOI 10.17487/RFC6454, December 2011, https://www.rfc-editor.org/info/rfc6454.

[RFC6455]: Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, DOI 10.17487/RFC6455, December 2011, https://www.rfc-editor.org/info/rfc6455.

[RFC6749]: Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, https://www.rfc-editor.org/info/rfc6749.

[RFC7022]: Begen, A., Perkins, C., Wing, D., and E. Rescorla, "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022, September 2013, https://www.rfc-editor.org/info/rfc7022.

[RFC7033]: Jones, P., Salgueiro, G., Jones, M., and J. Smarr, "WebFinger", RFC 7033, DOI 10.17487/RFC7033, September 2013, https://www.rfc-editor.org/info/rfc7033.

[RFC7675]: Perumal, M., Wing, D., Ravindranath, R., Reddy, T., and M. Thomson, "Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness", RFC 7675, DOI 10.17487/RFC7675, October 2015, https://www.rfc-editor.org/info/rfc7675.

[RFC8445]: Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, https://www.rfc-editor.org/info/rfc8445.

[RFC8825]: Alvestrand, H., "Overview: Real-Time Protocols for Browser-Based Applications", RFC 8825, DOI 10.17487/RFC8825, January 2021, https://www.rfc-editor.org/info/rfc8825.

[RFC8827]: Rescorla, E., "WebRTC Security Architecture", RFC 8827, DOI 10.17487/RFC8827, January 2021, https://www.rfc-editor.org/info/rfc8827.

[RFC8828]: Uberti, J. and G. Shieh, "WebRTC IP Address Handling Requirements", RFC 8828, DOI 10.17487/RFC8828, January 2021, https://www.rfc-editor.org/info/rfc8828.

[SWF]: "SWF File Format Specification Version 19", April 2013, https://www.adobe.com/content/dam/acom/en/devnet/pdf/swf-file-format-spec.pdf.

[whitten-johnny]: Whitten, A. and J.D. Tygar, "Why Johnny Can't Encrypt: A Usability Evaluation of PGP 5.0", Proceedings of the 8th USENIX Security Symposium, August 1999, https://www.usenix.org/legacy/publications/library/proceedings/sec99/whitten.html.

Acknowledgements 🫶

Huge thanks to Bernard Aboba, Harald Alvestrand, Dan Druta, Cullen Jennings, Alan Johnston, Hadriel Kaplan (Section 4.2.1), Matthew Kaufman, Martin Thomson, and Magnus Westerlund. you all made this doc better 💜✨

Author's Address 🎀

Eric Rescorla Mozilla

Email: ekr@rtfm.com

📦 where this page comes from

ietf: rfc8826 2021-01
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms