[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: HTTPS everywhere!

On Wed, 2014-06-18 at 14:20 +1000, Russell Stuart wrote: 
> Precisely.  It has a horrible design bug.
> Given the nature of the net, where we want to deal securely with some
> entity never dealt with or of heard of before  like, www.shop.com, we
> are forced to rely on a third party to assure us the DNS name
> www.shop.com really is owned by "shop.com".  This is what the X.509
> does.
Yep that's the problem...

> I am not aware of anything that could do it better.
Well there cannot be anything really better... this is the problem:
Either you meed all your peers in person, or you trust some 3rd party
(which usually means you're screwed, especially when this 3rd party is a
commerical CA)

The only "a bit better" is that you use a mix of a strictly hierarchical
PKI as X.509 imposes it... and a mesh, as imposed by OpenPGP, which is
what OpenPGP actually does:
A mesh, with trusted introducers. (see trust signatures for more

But again... this doesn't really solve the problem.

> So you need X.509 PKI (even with all its flaws) during that first
> contact.
I don't think so in our special case, at least not regarding Debian

A user of Debian already fully trusts us (by using our distro, where we
could do basically everything).

If he ultimately trusts our X.509 root, he doesn't give us more trust,
than he already did.
So we could very easily add it to any trust stores in Debian without any

Of course this still doesn't solve the problem of e.g. browsers, that
they have gazillions of CAs, and each could issue forged certs for
Debian hosts, but at least it technically allows the user (or programs
like apt-listbugs) to _really fully securely_ contact Debian services
via TLS/SSL with X.509 - something which is not possible with
GANDI/CAcert or any other non-Debian-managed CAs.

> But after you've sent them money or downloaded their software
> you have formed a trust relationship with whoever controls that cert far
> stronger than the assurances X.509 provides.  That is true in the
> positive sense if you receive your goods after paying, or the software
> you downloaded works well, or in the negative sense if the reverse
> happens.  Regardless, next time you deal with the entity that controls
> the www.shop.com cert, you now know far more about them than the X.509
> PKI does.
I don't quite understand what you mean here.

> The bug is the current system forces you to reply on X.509 for all
> future contacts, even though you have much better source of trust.
> During that initial contact the protocol could have arranged for you to
> download a cert signed by the owners of shop.com themselves, so you
> could reply on it in the future instead of X.509.  Suddenly all X.509
> issues, like MITM attacks, disappear.
Well more or less... this *is* the case ... or at least it can be done
when you use something like Certificate Patrol.
Then you verify whether it's still the same cert that you communicate
with (and only the shop owner should have the key).

But reality is: It doesn't really help you at all since:
- the attacker could have MitM you in the first place and even when you
- you loose the whole framework that allows key/cert changes
(renewals/revocations), etc.

So unfortunately you're idea doesn't solve anything, as before, you're
still fully dependant on ultimately trusting the root of the original

> For example, that initial contact creates a
> "bookmark" your browser stores so you can access the site again.  The
> bookmark embeds the cert from shop.com.
=> xul-ext-certificatepatrol
but note that this is unmaintained software, has several issues and it
only gives you a tiny bit more practical security... in the end you
still fully depend on the original root CA.

>   The advantage of this bookmark
> is it provides mutual authentication, so not only do you know the site
> is still owned by the same people - the site knows its you contacting
> them.
Erh what?
The site server still knows nothing about you, unless you'd generate a
client certificate and use client authz.
And then it still only knows about someone being the same client -
nothing about it's actual identity.

>   This means when you use the bookmark the site can reduce it's
> security demands - as in there is no need for you to remember super
> strong passwords.
=> TLS client authentication ;-)

>   It also means the site can pro-actively train you to
> behave in a same manner - as in make life easier when you use the
> bookmark to contact them.  So if you click on a phishing link  it
> suddenly becomes obvious you are not dealing with the real "shop.com".
Well but that's independent from any "bookmarking" system.
And TLS per se doesn't help you against pishing:
Usually pishing uses other domains/URLs which just look like the
original website and trick people into entering their credentials...
such site can easily give you a valid certificate for it's domain
The only thing that helps here is that a user closely looks, at the
subject of the certificate... if the users knows "I want to connect to
sskm.de" (a bank of Munich), but he sees a cert for "sskm.org" he could
notice that something is fishy.
EV certs don't really help you much more as the past has shown... since
there were cases of certs like (fictional example since I don't remember
the real case) "SSKM Inc." and "Stadtsparkasse München Inc."... both
actually existed (though the former was just a fake company) and the
CA/RA had not much chances to detect the fraud.
Users in the end believe "oh they're just using their acronym - well
that seems to be okay" => screwed.

> I had hoped they would address it
> in HTTP2.
HTTP2 is not directly about TLS... and anyway... you cannot solve the
problem per definition.
Either you trust "introducers" like our X509 CAs... or you manually
exchange some credentials with your actual communication peers.
That's the nature of public-key cryptography.


Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply to: