Search Mailing List Archives

Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[liberationtech] WebRTC - The next big surveillance machine

carlo von lynX lynX at
Mon Apr 7 02:35:51 PDT 2014

Summary (TL;DR):
    I predict ZRTP SAS has the potential of becoming the most
    widely accepted bootstrap method among people who care, if
    they insist on using non self-authenticating crypto tools,
    but it is not going to be good enough to hit mainstreet.
    Alternatives to ZRTP SAS are presented.

On Sun, Apr 06, 2014 at 04:01:07PM -0700, elijah wrote:
> This is an old thread, but this ietf draft is apropos:

That's the version from last August, here's the update:

and IETF even has a nifty tool to see the updates:

As we can see only a JSON representation has been added.

> It describes how you could use authenticate WebRTC streams using ZRTP
> implemented in javascript, even with existing browsers that use DTLS-SRTP.

That has two problems.
One concerning security, the other concerning usability.

Problem 1:

We have shown time and time again that we currently have no
secure way to bring Javascript into people's web browsers.
All methods either require a software installation or
delegating trust to the broken X.509 certification mechanism.
If ZRTP isn't provided with all web browsers as a built-in
functionality, WebRTC indeed has potential of becoming the
next big surveillance machine.

Problem 2:

I distinguish two styles of authenticating cryptographic
communications, "enabling" and "bureaucratic" ones. ZRTP
similarly to OTR and PGP are bureaucratic authentication
methods: You SHOULD be doing this procecdure to be safe,
but actually you already have a communication going, the
notion that somebody could have MITM'd you feels paranoid
and the procecdure gets annoying after a while. Majority
of people will go unsafe simply because they couldn't care
less. They just click the SAS prompt away. I notice the
problem also with OTR: half of my contacts are using it
opportunistically, risking MITM each day, even though I
wrote up a shared secret on a piece of paper last time we
met. In the case of PGP I am the pebcak myself: I catch
myself forgetting to check fingerprints after importing a
key from the server and enigmail has never tried to make
me configure the proper PGP settings. In my key store all
keys appear unauthenticated although I actually did auth
some. The fact that it is an extra bureaucratic transaction
to flag that makes it a total usability headcrash.

Enabling authentication procedures are Tor's hidden services
for example. If you don't get the fingerprint in the .onion
right you don't get a connection in the first place, so you
have a strong motivation to do that right. That's actually
the case with all public key routing technologies if the
path the public key took to get to your computer is safe.
So you may actually want to NOT put the public key into an
easy to copy-paste URL which will obviously be shared over
unsafe channels such as mail. Then again, if the channel is
a public mailing list or website, the agency would expose
itself a lot in falsifying such an obviously visible item -
so it doesn't actually happen (haven't heard of any case),
while when MITM'ing a ZRTP session people always have the
doubt something's wrong with their browser configuration
and can't easily prove the agency having attacked them.

At #youbroketheinternet we only pursue technologies that are
based on public key routing. For more than a reason. Tor is
actually the one with the flakiest implementation of it.

More information about the liberationtech mailing list