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 information) 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 users. 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 harm. 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 CA. > 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. Cheers, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature