On Wed, 2014-06-18 at 04:54 +0200, Christoph Anton Mitterer wrote: > Well https with X.509 has inherent problems which we won't be able to > solve...
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. I am not aware of anything that could do it better. So you need X.509 PKI (even with all its flaws) during that first contact. 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. 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. Unfortunately that's just the start. It's possible to imagine much stronger protocols. 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. 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. 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. 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". But are apparently welded to the current stuff, and as you say Debian is not in any position to change that. I had hoped they would address it in HTTP2. It's the ideal time. They are break forwards compatibility in all sorts of ways. But it doesn't seem to have entered their minds.
signature.asc
Description: This is a digitally signed message part
