Walkthrough · bit more complex. Encrypting Real Time Media WebRTC uses DTLS-SRTP for encryption....

Home Subscribe Contact cogint.ai – AI in RTC

webrtcH4cKS: ~ Does your video call have End-to-End Encryption? Probably not..

Time for another opinionated post. This time on… end-to-end encryption (e2ee). Zoom

apparently claims it supports e2ee while it can not satisfy that promise. Is WebRTC any better?

Zoom does not have End to End Encryption

Let’s get to the bottom of things fast: Boo Zoom!

I reviewed how Zoom’s implements their web client last year.

I’m not really surprised of their general lack of e2ee given that their web client did not provide

any encryption on top of TLS or WebRTC’s DataChannel. For reasons we will discuss below, this

means they weren’t doing any obvious e2ee there.

Update (April 2nd): Zoom published a blog post saying are using e2ee in the main use-case.

Which sounds great but how is that auditable, how are keys managed and what prevents them

from switching it o� at any time?

Is WebRTC Any Better?

Now that we’re done with �nger pointing, how does the situation look in WebRTC land?

WebRTC is encrypted. By default. You can’t turn it o�. It’s clearly secure! Sadly, the situation is a

Posted by Philipp Hancke on April 1, 2020

Posted in: Standards.

Tagged: DTLS-SRTP, e2ee, insertable streams, zoom.

12 comments

Email Address *

First Name

Last Name

Subscribe

Sponsored. Become a webtcHacks sponsor

apple BlackboxExplorationBriefChrome code computervision DataChannel debug

Search

search webrtcHacks.com

New PostNotifications

Tags

About

Does your video call have End-to-End Encryption? Proba... https://webrtchacks.com/you-dont-have-end-to-end...

1 of 8 4/30/20, 5:39 PM

bit more complex.

Encrypting Real Time Media

WebRTC uses DTLS-SRTP for encryption. In a nutshell that means there is a (D)TLS handshake

and then the encryption keys are derived from that. That uses self-signed certi�cates which are

signalled in the SDP. This is a fair bit better than no encryption or SDES.

source: https://twitter.com/matthew_d_green/status/1030809095375339521

DTLS vs. SDES

The slides from the 2013 IETF meeting in Berlin discuss the topic of DTLS vs SDES in quite some

detail and we also have a post on that decision if you want more history there.

There are two things to note here:

1. DTLS requires an active attack. It is possible (using chrome://webrtc-internals or Firefox

about:webrtc) to get hold of the remote DTLS �ngerprint of a peer you’re connected to. But

that is quite hard for the average user. It is possible to use end-to-end encryption for the

signaling messages which then establish a binding between an identity and the �ngerprint.

This even applies if your tra�c is routed through a TURN server, which by design does not

know the encryption keys negotiated via DTLS.

2. It is encrypted to the peer. Now in the multiparty case that peer is often a SFU. The same

Edge extension gateway

getUserMedia h.264 ICE ims ip

leakage janus jitsi kurento MCU media

server mozilla NAT opensource ORTCPromo Q&A raspberry pi

Safari screenCapture SDES SDP sfusimulcast standards TensorFlow

trace TURN video vp8

Walkthrough Web

Audio webrtc webrtc-internals

wireshark

Guide (55)Other (13)Reverse-Engineering (16)Standards (20)Technology (41)

Chad Hart on True End-to-EndEncryption with WebRTCInsertable StreamsHarold Benjamin Thetiot on TrueEnd-to-End Encryption withWebRTC Insertable StreamsJoao Paulo De Luca on Guide toWebRTC with Safari in the Wild(Chad Phillips)Tech roundup 71: a journalpublished by a bot - Javi LópezG. on Open Source CloudGaming with WebRTCMichael Briseno on YourBrowser as a Audio ConferenceServer with WebRTC & WebAudio (Alexey Aylarov)

Categories

Recent Comments

Twittering

RSS Feed


2 of 8 4/30/20, 5:39 PM

applies to Zoom. I looked at their native stu� a couple of years back and the payload of the

UDP packet seemed pretty random which suggests a similar level of encryption.

Selective Forwarding Units (SFU)

Now there is a thing about SFUs. This is the defacto architecture used to relay media in the cloud

when you need to scale a video conference past a few users. They need to do some fancy things

with RTCP, the control protocol for media in order to work. Oscar Divorra described the details

here and Gustavo and Sergio go into the details of layering here

They also need access to a tiny bit of information about the frame, in particular whether it is a

keyframe in order to make simulcast work. You can see some of this here.

This can be solved by a technique called “frame marking” which pulls that bit of information out

into an unencrypted header extension. The same goes for server-side speaker detection when it

comes to audio.

Note it is a di�erent story for 1:1 calls or calls that employ a peer-to-peer mesh architecture.

These do o�er e2ee by default – noting the DTLS caveats above.

WebRTC Insertable Streams to the rescue

Unlike an MCU an SFU does not need or want access to the unencrypted media. But they get it

because there is no alternative yet. However, this is about to change with the Insertable Streams

API that is being implemented by the Chrome WebRTC team right now:

source: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/Oy84pXDhajI/lu-Z0p3QAAAJ

It has been available in the native webrtc.org API for a while but Chrome bindings were missing.

It is far from ready and needs considerably more testing. There were some pretty glaring bugs

like not working in the other direction (�xed in less than 24 hours which was much appreciated).


3 of 8 4/30/20, 5:39 PM

Tubito Rodriguez

Reply

12 comments on “Does your video call have End-to-EndEncryption? Probably not..”

on April 2, 2020 at 9:54 am said:

Ah jeeze. Another reactionary article. Would have been more original if published before this

zoom �asco. Abysmal.

← Stop touching your face using a browser

and TensorFlow.js

Accelerated Computer Vision inside a

WebRTC Media Server with Intel OWT →

The bar is rising here but there is still quite some e�ort to be done before it is ready.

So yes, Zoom does not have end-to-end encryption. Quite often, WebRTC doesn’t either – not yet

at least. If you are using a WebRTC service check their terms of service and privacy policy and

make sure that you understand what they are saying about this. Hopefully we will see this

change soon as WebRTC Insertable Streams matures.

Disclosure: I had a co�ee with Eric Yuan, CEO of Zoom in early 2019 after he read (and hopefully

enjoyed) the original post on how Zoom avoids WebRTC. He paid for the co�ee and gave me

nice swag even.

{“author”: “Philipp Hancke“}

Want to keep up on our latest posts? Please click here to subscribe to our mailing list if you have

not already. We only email post updates. You can also follow us on twitter at @webrtcHacks for

blog updates.

Related Posts

True End-to-EndEncryption with WebRTCInsertable Streams

WebRTC MUSTimplement DTLS-SRTPbut… MUST NOTimplement SDES?

How Zoom’s web clientavoids using WebRTC(DataChannel Update)

WebRTC and Man in theMiddle Attacks

WebRTC standardizationis more than codecs –Q&A with Dan Burnett

WebRTC Video CodecDebate PositionsInfographic


4 of 8 4/30/20, 5:39 PM

Walkthrough · bit more complex. Encrypting Real Time Media WebRTC uses DTLS-SRTP for encryption....

Documents

Transcript of Walkthrough · bit more complex. Encrypting Real Time Media WebRTC uses DTLS-SRTP for encryption....