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.
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:
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.
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:
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.
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.
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.
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.
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:
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.
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:
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.
Even with the outstanding security mechanisms, your app is as secure as you design it. You can ensure appropriate security by:
Is it secure enough?
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.