WebRTC Encryption and Security: Everything You Need to Know (Update)

 

Web Real-Time Communications (WebRTC) is the fastest streaming technology available, but that speed comes with complications. Naturally, people question how a streaming method that transports media at ultra-low latency could adequately protect either the media or the connection upon which it travels. But there’s good news. Although WebRTC encryption and security can be complicated, it is strong. In this article, we will discuss WebRTC security vulnerabilities and how WebRTC addresses them. 

 

A Brief Intro to WebRTC

WebRTC is more than just a protocol. It is a collection of streaming technologies, including protocols, standards, and three JavaScript APIs. Among these is the User Datagram Protocol (UDP). This connections protocol stands in contrast to its counterpart, Transmission Control Protocol (TCP), in that it prioritizes speed over reliability.This combined with the open-source nature of WebRTC tends to reinforce the misconception that WebRTC is a vulnerable technology, but this couldn’t be further from the truth. 

Understanding WebRTC Communication

Before we dig into WebRTC security vulnerabilities and how it addresses them, let’s explore how WebRTC creates and maintains connections for the transport of media. People will frequently refer to the “WebRTC protocol”, but as we mentioned above, WebRTC is not strictly a protocol. It’s a collection of technologies, including three JavaScript APIs which work together to establish and maintain connections between peers and transport media across those connections. 

GetUserMedia

The getUserMedia API does pretty much exactly what it sounds like. It gets the user’s media from their webcam and microphone. Once upon a time, this was accomplished using third party plugins like Flash, but HTML5 changed the game with the introduction of this API. WebRTC happily utilizes it as part of its underlying technology.

RTCPeerConnection

RTCPeerConnection is a WebRTC specific API that uses the session description protocol (SDP) to establish a connection between peers. It’s also responsible for encoding the media and sending it across the established connection using the UDP. 

RTCDataChannel

Finally, there’s the RTCDataChannel API. This API handles non audio/visual forms of data. It’s responsible for transferring text and other alternative types of data across the connection established by RTCPeerConnection.

Technically, these and the browser upon which you are accessing the WebRTC application are all you need for a successful stream. However, this is not typically a scalable solution. Many people end up using this so-called serverless technology with a range of servers to facilitate communication and scalability. As we’ll explore in the next section, this introduces some additional security concerns. 

   

WebRTC Security Vulnerabilities and Considerations

WebRTC mandates encryption at the protocol level. It is subject to rigorous privacy and security controls when run inside a browser environment, but what about services that don’t use the browser? While WebRTC is primarily designed for browser-to-browser communication, it frequently uses a wide range of infrastructure devices that can complicate its security. The table below summarizes common WebRTC server types and their high-level security implications.

Infrastructure device	What it does	Security implications
Signaling server	Authenticates users, sets up and relays signaling information between clients	Significant — user credential information needs to be guarded; privacy and usage tracking implications (like any internet service)
STUN server	Response with a client’s public IP address	Minimal — some privacy / usage tracking implications
TURN server	Relays client media when a direct connection between peers cannot be established due to firewall or NAT traversal issues	Minimal  – some privacy / usage tracking implications but media is never decrypted
Media server	SFU, MCU, and live streaming servers that forward, mixes, and or save media from clients	Very significant — media server devices typically decrypt and encrypt media and are potential vulnerability points

Inherent Internet Security Issues

WebRTC signaling servers are essentially web application servers and need to be secured like any application. Users should be wary of who they are connecting to. Fortunately, browser and app store safeguards minimize bad providers – but bad users are another problem. “Zoom bombing” refers to obtaining video conferencing meeting information in order to join a meeting unauthorized, usually for disruptive purposes. WebRTC service providers can prevent this by giving their users authentication mechanisms that restrict entry to authorized users and leverage moderation controls to quickly remove and block bad actors. Wowza, for example, has APIs that control WebRTC stream access and duration.  

Media Server Risks

While other servers like STUN and TURN are sometimes needed, these never gain access to unencrypted media, and thus don’t present much of a risk. Other servers, particularly media servers like Selective Forwarding Units (SFUs) that enable multi-party video conference calls or live streaming servers, introduce more difficult risks. These servers decrypt the media before retransmitting it with new encryption keys. This decryption often cannot be avoided. If the media server needs to manipulate the media, then it must perform decryption to access that media. For example, in live streaming networks, the media server needs to decrypt the media to transcode it (resize, recompose, and convert the format) for use by a video content delivery network (CDN). 

If these media servers are compromised, then the user media streams could be at risk. It is important that media server operators follow best security practices when deploying their infrastructure and managing authorized users. As such, these servers should avoid unintentional caching of sensitive unencrypted data. Additionally, they should isolate the media streams internally from other processes to further avoid unauthorized access.

Security should be application specific. For example, you may need to record and archive media for intentional distribution. In that case, the stream will certainly need to be saved to a disk and made at least somewhat available. Security measures should dictate how this is done and by whom. They should also establish who can access and play back the media. 

 

Types of WebRTC Security

WebRTC is a complex, layered technology that exists in a likewise complex, layered ecosystem of application code, browsers, native devices, and infrastructure elements. WebRTC approaches security from several different angles. First, it is secured at the protocol level. Second, using the browser as a reference, it requires a protected and private execution environment. Third, it follows best security practices by engaging its community of developers. 

WebRTC Protocol Security

WebRTC protocol security comes down to securing two main elements: the signal used to help two peers communicate with one another and the media they share between them. 

Mandatory Media Encryption

Unlike other VoIP and video conferencing technologies, encryption is mandated in WebRTC. To send video, voice, or data between two peers in WebRTC, the information must be encrypted with Secure Real-time Transport Protocol (SRTP). SRTP encrypts the session, so no one can decode the message without the proper encryption keys. In fact, the unencrypted version of the Real-time Transport Protocol (RTP) is explicitly forbidden by the Internet Engineering Task Force (IETF) specifications that define WebRTC.

Mandatory Secure Encryption Key Exchange

Additionally, the WebRTC specifications mandate secure setup of the encryption channel to make it difficult to obtain the WebRTC encryption keys. Locking your house doesn’t do much good if it is easy to find the key under your doormat. Many key exchange mechanisms, such as SDES, MIKEY, and ZRTP may be used to set up this encrypted channel. Systems like SDES and MIKEY leverage the signaling channel to transmit this key data. This means if the signaling channel is compromised, then the data could be unencrypted by a third party. To prevent this possibility, the WebRTC specifications mandate the use of DTLY-SRTP where keys are exchanged directly between peers on the media plane. Even though SDES is still widely used by many VoIP systems, it is specifically barred from use in WebRTC because it is not secure enough. 

Secure Signaling 

Lastly, WebRTC requires a secure connection between the web server that handles signaling and the peer client. This helps to keep the information in that signaling channel secure and makes it more difficult for an attacker to act as a man-in-the-middle and quietly take over the session. Signaling is secured using the HTTPS protocol – the same one most websites now use.

In live streaming environments, the server acts as both a signaling server and WebRTC media peer, but the same secure interfaces are used. Note the above image that illustrates WebRTC security points in a peer-to-peer architecture, providing end-to-end encryption (also sometimes known as P2P encryption). Below you’ll find a similar workflow demonstrating a live streaming architecture as with Wowza Streaming Engine.

Browser Based Security

WebRTC is further secured by operating in a browser sandbox. Web browsers are the most commonly used applications and have developed sophisticated security and privacy features. These features help to isolate web applications, keep sensitive user information like credit cards secure, and protect against browser hijacking. 

Browser Security and Privacy Protections

Browser vendors are subject to strict security standards as defined by the W3C and underlying Internet specifications, like those for WebRTC. What’s more, competition among major browsers like Chrome, Firefox, Edge, and Safari has led them to ramp up user security and privacy protections both in general and particularly for WebRTC. Specific examples include: 

• HTTPS: Use of HTTPS, as opposed to HTTP, is required to access WebRTC features (with some small exceptions for development). 
• Media access permissions: Users must explicitly grant permissions to individual sites before they can access camera, microphone, or screen sharing video.
• Visual usage indicators: Prominent indicators must show when camera, microphone, and screen sharing are active. 
• Anonymizing device information: Device information remains hidden until the user has given permissions to the site. 
• IP Leakage protections: Limitations on and options for sharing IP address information help avoid privacy and tracking issues. There are several tools circulating online to further help prevent WebRTC IP leakage, including Google’s own WebRTC Leak Prevent.
• Same Origin Policy (SOP): This essentially isolates webpage use instances to discreet “sandboxes” by limiting how documents or scripts from one web origin can interact with those from another. Basically, it puts a fence up around your website experience to protect it from malicious data.   

It’s worth noting that implementation of these features can vary from one browser to another, but most are similar across major browsers like the ones listed above. It’s also worth noting that many native mobile applications utilize some or all of these features via an embedded browser framework. Major mobile operating systems, like Android and iOS, implement similar controls, as well as additional security checks, for app store submissions.

Security by Design

There are two main philosophies when it comes to digital security:

• Security by obscurity: Keep the mechanisms of your system secret to make it harder to discover and compromise. 
• Security by design: Make the mechanisms of your system open, invite others to try to break in, and improve the design through feedback. 

Security researchers and organizations generally do not condone the first philosophy. For example, the National Institute of Standards and Technology (NIST) says “System security should not depend on the secrecy of the implementation or its components.” It is well known that secrecy never lasts forever, especially in the face of motivated adversaries. 

WebRTC subscribes to the security by design philosophy. Communication across browsers and devices over the internet requires open standards, so WebRTC has little choice but to comply at the protocol level. However, for security by design to work, it needs to have broad scrutiny. The browsers that run WebRTC are all open source (e.g., WebKit for Safari, Chromium for Chrome and Edge, Gecko for Firefox) and thoroughly tested. WebRTC is also open sourced and accompanied by dozens of different implementations which are actively supported by thousands of developers. These developers constantly review and improve on all aspects of WebRTC, security included.

   

Conclusion: Is WebRTC Secure Enough?

No software system is perfectly secure, and WebRTC is no exception. For example, a Google Project Zero security researcher published a major exploit that worked on seven out of 14 of the most popular Android WebRTC applications. On one hand, it is very bad that such a serious issue could have found its way into applications used on billions of devices. On the other hand, it’s encouraging that deep security vulnerability research was done in the public domain and resulted in all but one of these applications rapidly fixing their issues.

As with most software, there are a few general rules WebRTC developers can follow to limit attacks and minimize vulnerabilities: 

• Keep core WebRTC libraries up to date: Old code generally has more vulnerabilities.
• Pay attention to bugs and security notices: Major WebRTC projects and browsers are generally very proactive with their notifications (if you know where to look).
• Turn off pieces of code you don’t use: WebRTC is a large and comprehensive system that many apps only need a part of. Turning off excess code minimizes the attack surface. 
• Test and conduct RTC-specific security research: If you don’t find your issues, someone else eventually will.
• Secure your infrastructure. WebRTC may be secure, but if you web or media servers are insecure, they could compromise the system. Consider features like Wowza’s publication authentication that limits stream hijacking opportunities.

WebRTC is used every day by billions of people. Its security may not be perfect, but it is effective. WebRTC mandates security at a low level, often working with an established security sandbox (the browser) and encouraging review by large and very active community. 

If you are looking to take advantage of WebRTC on a larger scale and are concerned about the added risks that WebRTC media and signaling servers provide, consider streaming with an established provider. Wowza Video’s Real-Time Streaming at Scale is a cloud-based solution that can stream WebRTC to a million via a custom CDN. Additionally, Wowza is a SOC 2 certified company, meaning security is just as valuable to us as it is to you.

*This blog was originally written by Chad Hart in 2020 and revised by Wowza in 2023 to include the most up-to-date information.