Re: SSL/TLS everywhere fail

On 12/6/15, Amos Jeffries <squid3@treenet.co.nz> wrote:
> On 6/12/2015 11:59 a.m., Jacob Appelbaum wrote:
>> On 12/5/15, Poul-Henning Kamp wrote:
>>> --------
>>> Jacob Appelbaum writes:
>>>
>>>>> 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.
>>>
>>> Jacob, that's a false dictomy and you know it well.
>>
>> Not exactly. We have started with unencrypted connections that lack
>> confidentiality, integrity and authenticity. Moving to TLS gives us
>> all three with a computational cost and within certain boundaries.
>
> The tired old argument against "TLS-everywhere" is that TLS does *not*
> offer all three of those.
>

That argument is wrong when we consider how it is used in practice. As
an example, we upgrade a protocol from HTTP to HTTPS - we gain those
properties within certain bounds.

>
> * TLS does not offer confidentiality. TLS MiTM is commonplace now. It
> has even reached the point where traffic metadata can be recorded and
> correlated without decrypting the content of the stream.

Huh, please MITM my connection to my chosen Tor guard?

I'll concede you are correct when you can do so. You won't do so
unless you run a Tor guard and I choose you but that is of course, not
breaking the properties of TLS.

In many web browsers, you may be able to MITM them and if you choose
torproject.org with Chrome, even with a CA, you won't be able to MITM
the traffic in a way that breaks confidentiality unless you are my
chosen CA.

The exception is website fingerprinting - in that sense, I'll concede
that TLS has failures on large websites with know datasets. Especially
with SNI leakages and very specific websites that have very few pages
and an encrypted model is easy to build. Though that is probabilistic
rather than certainty.

> * TLS does not offer integrity. TLS MiTM can corrupt the messages inside
> encrypted streams just as easily as thay can for un-encrypted traffic.

An active MITM must first break the authentication between a client
and a server. To claim that because this can be done, TLS doesn't
offer integrity is... not even worth a debate, I'm sorry.

> When used with 2-way certificate verification TLS can offer
> authenticity. But that is still a rare situation to actually see
> implemented. Instead we see all sorts of half-measures (eg. HSTS, cert
> pinning)

It isn't perfect and again, when we consider HTTP, we see that the
improvement is in every area with regard to... transport layer
security. Is it a perfect solution? No. Why not? Because it can be
destroyed by ... a TCP RST packet. There are dozens of other reasons
that TLS isn't perfect. But there are as many more reasons for
unencrypted protocols and those are suffering active and passive
attacks in an automatic fashion.

> The benfits of TLS only occur when it is used properly in the situations
> where it is the best tool. The "TLS everywhere" drive with its over
> hyped arguments (and outright lies at times) is seriously undermining
> those benefits by pushing it out into every possible connection no
> matter how unsuitable TLS is for the use-case or broken the implementation.
>

I'm afraid I'm not familiar with the outright lies, could you cite
some and explain how they are lies? Can you for example cite them in a
way that makes them relevant to our discussion?

> The push back against "TLS everywhere" is attempting to ensure that
> those privacy/confidentiality and security/integrity/authentication
> goals can actually be *achieved*, instead of undermined by a rushed and
> broken rollout that leaves the whole world in a worse place than
> un-encrypted rollout did.

Great, I look forward to your improvement to TLS. TLS is an
improvement for most protocols, especially HTTP. Perhaps it will be in
TLS 1.3? That protocol seems quite wide open and if you can come in
and break it, we can perhaps find a way to fix it before the standard
is finished.

> Lets slow down the hype train and do it *right*.

Could you define "right" in a world of ongoing, pervasive mass surveillance?

>
>> Some object to confidentiality, others to integrity and so on. A lack
>> of action on this has ensured that some protocols stay unencrypted -
>> an explicit goal of some of the bad actors who are present as agents
>> of influence in this (and other!) standards body.
>
> Please do not equate TLS with encryption. Encryption is much bigger than
> TLS. A fact that the "TLS everywhere" fanatics are constantly shouting
> out with their insistence that anyone doing encryption in non-TLS
> settings is Bad Thing.

{HTTP,IMAP,POP} to {HTTP,IMAP,POP} with TLS makes for a transition
from unencrypted to an encrypted connection. Other than with say, the
null cipher, of course.

The second part of your statement doesn't make sense to me and sounds
like a straw man. I'd love to see a citation to better understand your
view. In any case, I'm not saying whatever someone else may have said
about encryption, so could you clarify?

> (I know you are not thinking of protocols like DNSSEC, VPN, or VPE as
> unencrypted, but the implication is there.)

Huh? DNSSEC isn't encrypted and most VPNs are garbage encryption. The
few that aren't are personally or professionally run by Paul Wouters
and a handful of IETF people.  My deepest respect to them, by the way.
Basically everyone else is out to sea on a raft of backdoored crypto,
held together with SIGINT and denialism. Or they're using VPN
protocols which aren't specified by the IETF, sadly.

All the best,
Jacob

Received on Sunday, 6 December 2015 08:28:25 UTC