A WebRTC Security Primer

Listen

do you want to know a secret

do you promise not to tell

“Do You Want to Know a Secret” – Lennon and McCartney

There are a number of reoccurring themes in my blog articles and security is near the top of the playlist. If you’ve been a long time follower of mine, you’ve read about securing SIP signaling with Transport Layer Security (TLS) and media with Secure Real-Time Protocol (SRTP). I’ve also written extensively about providing intrusion security with session border controllers. Today I want to spend some time on my latest kick – secure WebRTC.

In case you are new to WebRTC, allow me to give you a one paragraph definition. However, I highly recommend that novices read my article, WebRTC for Beginners before tackling this one.

WebRTC is a technology that allows web browsers to send and receive real-time media.  With WebRTC, a user can go to a web page and use that web page to make an audio or video call.  Media is subsequently sent directly to and from the web browser.

The key word here is directly. There is no requirement that any specialized hardware, such as an SBC, be situated between the web browser and the far-end. One web browser can send and receive real-time video to another web browser across any Internet connection.

Since the Internet is inherently an open, non-secured environment, it is imperative that the all WebRTC traffic be encrypted before it leaves the user’s device. For that, the WebRTC developers have settled on two protocols – DTLS and SRTP.

Datagram Transport Layer Security (DTLS) is used to provide communications privacy for datagram protocols. This fosters a secure signaling channel that cannot be tampered with. In other words, no eavesdropping or message forgery can occur on a DTLS encrypted connection.

DTLS is based on the same principals as its stream oriented counterpart, Transport Layer Security (TLS), and provides the same levels of security. This means that web browsers exchange DTLS handshakes on every voice, video, and data channel.  While this handshake (two round-trips) adds some latency to peer-to-peer setup time, it should not be an issue for most connections.

---

For a companion piece, please see An Introduction to the Opus Codec.

---

If you’ve worked with SIP for a while, you should be familiar with Secure Real-Time Protocol (SRTP). Like DTLS, SRTP works with unreliable, datagram protocols like UDP. However, DTLS encrypts WebRTC signaling while SRTP deals strictly with media.

SRTP media cannot be decrypted by rogue players thus ensuring that IP communications across an open medium such as the Internet remain private.  With SRTP, your WebRTC voice and video traffic will not be heard or seen by unauthorized parties.

The WebRTC specification also offers developers the ability to use Session Description Protocol Security Descriptions (SDES) instead of DTLS, but that seems to be quickly falling out of favor. Google’s Chrome browser no longer supports SDES and Firefox has never offered support for SDES. Both browsers do support DTLS-SRTP and that appears to be the on-going choice.

I mentioned that an SBC is not required for browser-to-browser WebRTC calls. That is most likely not the case with browser-to-PBX communication. In those instances, enterprises will probably want an SBC on their network edge to both protect their network internals and to perform gateway functionality such as WebRTC to SIP.

Mischief Managed

I could certainly go on for quite a bit longer about DTLS-SRTP and WebRTC security, but this should be enough to get you started. The key point is that you don’t sacrifice privacy with WebRTC no matter how open your network connection might be.

Tags: DTLS, Security, SRTP, WebRTC