[Ach] Certificate Authorities and Self-signed crap

[Aaron Zauner]

On 14 Dec 2013, at 20:07, Ulrich Poeschl <ulrich.poeschl at bmlvs.gv.at> wrote:

> In terms of security, why not? Because the marketing-deparment will complain. But hey. I don't care about them. :)

I wouldn’t either, but this paper is intended for admins/ops people and IRL most of those people work for companies. […]

> of course I get what you mean. but you are talking about "user friendiness" and "frictionless" interoperability here, not about "better crypto”.

Actually I’m not sure that recommending self-signed CAs is in fact “better crypto”. And this statement is probably going to cause a lot of discussion, so let me explain; x509 was desgined to be a trust chain, not a compartmentalized system. Needless to say that a telephony protocol was the wrong choice for trust chains in a global network of autonomous systems interacting with each other. If a root CA get compromised the whole system is fucked. Big commercial CAs do not always employ the best security as recent history has shown. But what I’ve seen from people running their own CA is far worse in 80% of the cases. Then there is the obvious issue with how to trust a CA. Do I just blindly trust it as a user? And if I do so what if that CA is signing malicious third-party website certificates? That is exactly how DPI solutions are implemented in large companies throughout the united states and in parts europe. If everbody would employ self-signed CAs and people would accordingly install them and check fingerprints, it would also be a new angle of security attacks: You now have thousands of CAs you can compromise, most won’t conform with standards (just as commercial CAs do not *) and thus one can simply compromise a single CA and sign away.

I think the security community is slowly reaching consensus on that topic: x509 will need to be replaced by a better solution sooner or later. Although my guess is that it’s going to take quite some time.

> if you are a corporation that is serious about the protection of the data transferred you _have to_ "force" your users to
> 
> - manually install your selfsigned CA-cert
> - verify the fingerprint
> 
> before they start working with you.
> 
> startssl is not "better crypto". but hey, it's in my browser.
> 
> of course you can't get weekend-users to do that, but weekend-users are also not the ones reading this paper and learning about "NSA-proof cipher suites".
> 
> see abstract: "This guide arose out of the need for system administrators ..."

So what Google did was to implement such functionality into their product (Chrome) so the user does not really have to. Which is somewhat the wrong way to do things, because it does not educate endusers. Then again it’s a big tradeoff for them. They’re also pushing for better protocols: http://www.certificate-transparency.org/ (e.g.)

We want to reach a wide audience, including people who run large hosting infrastructures (because they do a lot of SSL/TLS traffic, right?). I don’t think it’s the right choice to state that only self-singed CAs should be used. And I acutally think that would do harm to the credibilty of this paper. Not because it’s wrong from a security point of view. But from a practical point of view.

This is exclusively stuff that concerns sysadmins and ops people in general. And I do not know of a single person in that business that is happy with what commercial CAs are, how they are implemented and operate. But again: We are already dependend on that system of trust and as long as we do not have a widespread replacement option we're bound to deal with it as best as possible. So if you’re running facebook/twitter/qq/.. you probably won’t use a self signed CA, and won’t take advice that says you should serious, no?

It is my honest opinion that X.509 is a bullshit protocol that is not fit for 21th century internet traffic and that it should be replaced rather than worked around (which will cause even more security issues).

Please discuss how you’ll want to procede on the topic and section of certificate authorities in the paper. I’ve stated my position :)

Aaron

* - see this fitting comment by Peter Gutmann on keyusage as committed to the Go sourcecode’s x509 part: https://code.google.com/p/go/source/browse/src/pkg/crypto/x509/verify.go#173
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1091 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.cert.at/pipermail/ach/attachments/20131214/75ed1490/attachment.sig>