W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2015

Re: SSL/TLS everywhere fail

From: Jacob Appelbaum <jacob@appelbaum.net>
Date: Sat, 5 Dec 2015 15:10:35 +0000
Message-ID: <CAFggDF1ckgL+mGN5NJKv9-Mj5b6MDkHdJC+3SVo=JJ2pKQd=iw@mail.gmail.com>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc: Mark Nottingham <mnot@mnot.net>, Cory Benfield <cory@lukasa.co.uk>, Adrien de Croy <adrien@qbik.com>, Mike Belshe <mike@belshe.com>, Amos Jeffries <squid3@treenet.co.nz>, httpbis mailing list <ietf-http-wg@w3.org>
On 12/5/15, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
> --------
> In message <BE05C37D-61A7-43DC-9A7A-E7E1A6B2C5EB@mnot.net>, Mark Nottingham
> wri
> tes:
>
>>MiTM was a COTS product long before people started agitating for "TLS
>>everywhere." It may have enlarged that market, but the technology was
>>already there, and already a viable business for several vendors.
>
> And that is *exactly* why people should have thought "Hang on, If
> TLS-everywhere is easly defeated by COTS products..."

The model here is a bit strange. HTTP withou TLS is also easily
defeated. There is a cost here that is higher for the adversary and
that includes a political one: detection.

>>> The correct response would have been to roll out more or less
>>> *exactly* what the encryption draft contains, along with a wide
>>> number of diverse key-management schedules.
>>
>>I'd encourage you to talk to some browser security teams to understand
>>why that is not at all a viable replacement for TLS. The W3C's Web
>>Application Security Working Group is a good place to start.
>
> Nobody is talking about it being a "viable replacement for TLS",
> and we don't need a "viable replacement for TLS", we need technical
> response that can be ramped up, and up, and up, in response to the
> other sides increasingly desparate attempts to break it.

I think we need a viable replacement for TLS where it is harder to
censor - layer violations ensure that an attacker can just TCP reset,
while off-path. TLS 1.3 with DTLS may be much harder to censor, for
example.

>
> No, it won't be plug in, and no, it may not make people the same
> amount of money as usual.  But it *might* push our political
> agenda forward as a means of "civil disobedience".

I generally think that this is a good idea but it also misses a
critical pressure point: when we all use similar protocols, we can
help each other by blending in at the network level.

>>I think you're creating a straw-man here. No one has said that TLS
>>everywhere is the only solution, or even a sufficient one.
>
> Ohhhh yes, a lot of people said that, also in this group.  I've
> personally heard Jacob say it both in public and in priave over a
> beer.  And yes, I shared my view.
>

In defense of Poul: I have absolutely said that I think TLS helps make
the internet harder to govern from the desk of a censor. I also think
this is useful at times. We'll see how it plays out in the current
context of this particular country.

I think in many places - the cost of blocking all TLS is too high - so
selective blocking is required. That has been sufficient to change the
same. In some countries, we've seen the local censors give up or the
attacker math meant they focused on attacking Skype or something else
that was more pressing.

>>>       http://telecom.kz/en/news/view/18729
>>
>>Interestingly, that now redirects to their home page. It's hard
>>to say for sure, but I suspect they were surprised by the reaction
>>and are re-thinking their plans. I suppose we'll (eventually) see.
>
> Rumours from local sources is that it simply took their webserver
> down.  No rumours about the government decision having changed.

Now would be a good time to have diplomatic contacts reach out and to
confirm, as well as to discuss the future. Which would be a joke
topic, if it wasn't being discussed openly, which may have not
happened if it wasn't going to be a detectable event...

The change can't come from technology alone but for sure the ability
to ignore that it is happening is a good change.

All the best,
Jacob
Received on Saturday, 5 December 2015 15:11:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:40 UTC