Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
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
Does your video call have End-to-End Encryption? Proba... https://webrtchacks.com/you-dont-have-end-to-end...
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).
Does your video call have End-to-End Encryption? Proba... https://webrtchacks.com/you-dont-have-end-to-end...
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
Does your video call have End-to-End Encryption? Proba... https://webrtchacks.com/you-dont-have-end-to-end...
4 of 8 4/30/20, 5:39 PM