WebRTC is a real-time communication technology that allows making audio and video calls directly from a web browser. It is known for its outstanding security that makes WebRTC the leader of the pack. By building your communication app on top of WebRTC, you are going to leverage the inherent security mechanisms contained in the underlying technology and ensure that your chat or calling app provides the best protection to its users.
Let’s glance under the hood of WebRTC security and see how this technology achieves the level of protection and privacy required from any communication app of today.
Security mechanisms used in WebRTC
WebRTC focuses heavily on security applying appropriate security mechanisms at its very core. The diagram below illustrates the WebRTC protocol stack showing all the technologies that are used to enable its connection, data transfer, and encryption features.
The following components contain security mechanisms:
- SRTP
- Session (TLS)
- Session (DTLS)
WebRTC signaling
The components on the left-hand side of the diagram provide signaling in the browser. For signaling, WebRTC uses inherently encrypted protocols – TLS or QUIC- rather than non-encrypted signaling channels. The use of non-encrypted channels is possible but they may be restricted by certain browsers or request access to the user’s mic and camera upon the start of each session. We do not recommend WebRTC-based deployments over non-encrypted signaling channels.
In WebRTC, encryption is a mandatory process. At the same time, in matters like authentication and identity management you can choose whatever suits you best and use any mechanism that provides a sufficient level of security. That concerns any applications you build – mobile or desktop; the only thing that is absolutely required is encrypted signaling.
Media security in WebRTC
The primary purpose of WebRTC is media communication, and this is what the technologies shown on the right-hand side of the diagram are for.
Any data that passes through WebRTC is always encrypted. All audio and video streams are sent via SRTP. The scheme implementation requires the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite and the P-256 curve. The cipher suite is regularly updated with newer versions to ensure protection against new attacks.
The WebRTC specification states explicitly what is required and what is prohibited within the context of WebRTC security.
Similar to audio and video channels, data communication channels use DTLS and are always encrypted.
To obtain a shared private key for an SRTP session requires using DTLS-SRTP. This mechanism prevents fraudsters from discovering the key. To increase security, SDES is prohibited, too, meaning that keys cannot be sent in their initial form even over secure channels. With regards to signaling channels, WebRTC prefers the “zero trust” approach.
The WebRTC security architecture explicitly states that these security mechanisms are always mandatory:
- Implementations MUST support SRTP;
- Implementations MUST support DTLS and DTLS-SRTP for SRTP keying;
- Implementations MUST support SCTP over DTLS;
- All media channels MUST be secured via SRTP and SRTCP;
- Media traffic MUST NOT be sent over plain (unencrypted) RTP or RTCP;
- implementations MUST NOT negotiate cipher suites with NULL encryption modes;
- DTLS-SRTP MUST be offered for every media channel;
- WebRTC implementations MUST NOT offer SDP Security Descriptions or select it if offered;
- A SRTP MKI MUST NOT be used;
- All data channels MUST be secured via DTLS.
In DTLS-SRTP, the certificate fingerprints of self-signed and auto-generated SDP certificates are exchanged, and the certificates are matched against the DTLS handshake during connection establishment. Media encryption keys are created at time of the handshake and exposed only to the two participants of the connection. The only threat is a possible man-in-the-middle attack at the signaling server.
In case your application uses a media server, it becomes a trusted entity. Consequently, the encryption is terminated at the server.
Access to the camera and microphone
Usually, if an application requires access to the microphone and camera, it asks the user explicitly for such access. Access to the mic and camera is never automatic, unless, of course, this is your own app.
In some browsers, the access permissions granted by the user are stored between sessions, while others request access with each new session.
In addition, the access request popup cannot be edited by the app. This way, fraudsters cannot modify the dialog windows to trick users into making wrong decisions.
Screen sharing permission
In any browser, a WebRTC app will ask the user’s permission to share their screen. Each browser has a special dialog window for that purpose.
These permissions are never stored until the next session, meaning that the user will need to grant permission each time.
In any browser, there is a floating window where the user can stop sharing their screen. These windows cannot be modified by app developers.
Local IP and privacy
For all its advantages, WebRTC used to have a privacy issue that created many concerns – it exposed the browser’s local IP address to send it over the signaling channel with JavaScript. This issue has now been resolved by adding mDNS.
WebRTC security in the context of open-sourcing and standardization
An important aspect about WebRTC has been mentioned in the previous section and that’s the fact that WebRTC is both open source and standardized.
One of the key characteristics of WebRTC is that it is open-source and standardized. Standardization adds a lot of time and resource consumption to the development, which can explain why there is no standard WebRTC specification yet, although it has been in the draft stage for a long time.
However, when it concerns security, the standardized approach is more preferable than the proprietary one. The reason is that when you develop for a community you are more concerned with security than when you develop for a standalone company. You may even place security higher than business needs.
Moreover, WebRTC was initially designed to be run in a browser which immediately means a higher degree of danger and malicious attacks.
WebRTC security supported by popular browsers
In browsers, security has a primary focus. Browsers stand between users and the great expanse of the Internet, and therefore, are required to protect users from multiple threats out there. This is why every major browser is always improving its security mechanisms.
Within the context of WebRTC security, here are some considerations worth mentioning:
- Browsers issue updates on a regular basis. Thus, WebRTC is always as updated as it can be and is, therefore, the most secure. At the same time, application vendors also need to keep up with browser updates by ensuring regular updates of their products.
- Since WebRTC depends on browsers, its security rests on the browsers’ security mechanisms that are much more reliable than those implemented in any VoIP product.
- Browser security can be illustrated by the results of the WebRTC fuzzing experiment that involved fuzzed messages intended to detect security vulnerabilities that were subsequently fixed.
When we are talking about browsers, we are talking about something that is available to billions of users at any given moment. Their security measures and mechanisms are designed to withstand such loads and prevent threats at such scale. WebRTC rides on top of these powerful security measures providing similarly secure service.
Proprietary products are less secure
You may consider using a proprietary solution rather than WebRTC for your video communication product, but be aware that you will not get the same level of security. The reasons are multiple:
- Any proprietary solution is designed and developed by a relatively small team. It can never compare to an open-source product that is analyzed, tested, tried, and examined by communities much larger than any QA team.
- Any business developing its own proprietary tool or product is primarily interested in making profit. It has a budget that it has to stay within. In such circumstances, security may become less important than user-facing features that get a bigger share of investments.
- Without WebRTC, you need to find a way to run your product in a browser. Some of the possible methods are not exactly safe and can cause security issues in your product.
- It is never recommended to develop your own security solutions. In this case, the protection of the entire app and all its users’ data depends on the professionalism of your team, and any small error can cause a massive disaster.
In older VoIP technologies, for example, SIP and H.323, security mechanisms are optional and sometimes not even enabled by default to free the capacity to run the actual product. At a certain moment, many developers even considered running media solutions without restrictions but that turned out not a very good idea.
WebRTC takes the most optimal approach to today’s networks – the “zero trust” approach. In each component, security mechanisms are to be implemented independently of any others.
What you can do to increase your WebRTC-based app security
Even with the outstanding security mechanisms, your app is as secure as you design it. You can ensure appropriate security by:
- Implementing security mechanisms that can fulfill the requirements of your app in addition to the inherent security of WebRTC. Remember, we mentioned authentication and identity management? This is where you can add a layer of protection.
- Ensuring proper implementation of WebRTC security mechanisms within your application.
- Paying attention to obvious mistakes that can cause major security breaches, such as using an outdated server or insufficient testing.
WebRTC security FAQ
Is it secure enough?
Yes.
The security of WebRTC is based on two great pillars – its initial design was security-focused, and it runs in browsers that are considered insecure by default.
It has its issues, of course – who doesn’t? – but they are fixed as soon as they are detected with frequent updates delivered to users almost immediately.
How to deal with WebRTC IP leak?
During the operation of WebRTC, local IP addresses are collected and shared. To prevent any possible privacy issues, mDNS has been implemented.
Is it possible to share unencrypted media via WebRTC?
No. WebRTC encrypts any media that is exchanged by users. It will not allow any unencrypted content to be sent over its channels.
Is any product using WebRTC secure by default?
No. You should implement other security mechanisms required by your app in addition to those provided by WebRTC. Its security does not cover all components of your system, so you need to take care of adequate security measures.
Is there end-to-end encryption in WebRTC?
There is end-to-end encryption between terminating entities. In peer-to-peer communication, the entire service is secured with end-to-end encryption. If there are media servers en route, they may be accessing unencrypted data.
Which is more secure, WebRTC or Zoom?
Such a comparison is not exactly correct.
WebRTC is a technology with a high degree of inherent security. However, applications based on WebRTC can be insecure due to faults in their design.
Zoom is a proprietary product focused on features other than security. There may be hidden issues that cannot be discovered by the community.
So, we can say that WebRTC is more secure than Zoom but their approaches to security are different.
