But that is quite hard for the average user. It is possible (using chrome://webrtc-internals or Firefox about:webrtc) to get hold of the remote DTLS fingerprint of a peer you’re connected to. 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. This is a fair bit better than no encryption or SDES. That uses self-signed certificates which are signalled in the SDP. In a nutshell that means there is a (D)TLS handshake and then the encryption keys are derived from that. It’s clearly secure! Sadly, the situation is a bit more complex. Now that we’re done with finger pointing, how does the situation look in WebRTC land? Which sounds great but how is that auditable, how are keys managed and what prevents them from switching it off at any time? Is WebRTC Any Better?
Does cryptocat have end to end encryption update#
Update (April 2nd): Zoom published a blog post saying are using e2ee in the main use-case. For reasons we will discuss below, this means they weren’t doing any obvious e2ee there. 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. I reviewed how Zoom’s implements their web client last year. Let’s get to the bottom of things fast: Boo Zoom! Is WebRTC any better? Zoom does not have End to End Encryption Zoom apparently claims it supports e2ee while it can not satisfy that promise. This time on… end-to-end encryption (e2ee).
0 kommentar(er)
