5

Why are certificate authorites allowed to issue certificates trusted by browsers for any domain name?

Doesn't that imply that one highjacked root certificate authority can issue trusted fake certificates that any browser trust. This is not very secure from an end user perspective.

Would it not be more secure that you designate which root certificate authorities are allowed & trusted to sign certificates for your domain name records for example via DNS SEC? Similar DNS examples are also mail SPF records where you say which mail servers are allowed to send mail from your domain.

Why is it designed to trust all root CA to issue certs for any domain name?

eightShirt
  • 303
  • 1
  • 3
  • 12
Christian
  • 265
  • 1
  • 3
  • It'll be hard to answer that one defiantly. It's just terrible that way. – StackzOfZtuff Jan 22 '16 at 22:05
  • 1
    Possible duplicate of [How feasible is it for a CA to be hacked? Which default trusted root certificates should I remove?](http://security.stackexchange.com/questions/2268/how-feasible-is-it-for-a-ca-to-be-hacked-which-default-trusted-root-certificate) – Ohnana Jan 22 '16 at 22:05
  • @StackzOfZtuff Defiantly or definitively? LOL, or neither? – Brad Bouchard Jan 22 '16 at 22:08
  • 1
    @BradBouchard yeah. I blame that one on autocorrect. ;) – StackzOfZtuff Jan 22 '16 at 22:18
  • 2
    This doesn't seem like a duplicate of "How feasible is it for a CA to be hacked? Which default trusted root certificates should I remove?" as that doesn't mention DNSSEC as a possible alternative implementation. – Neil Smithline Jan 22 '16 at 22:22

3 Answers3

6

Why is it designed to trust all root CA to issue certs for any domain name?

This has historical reasons and maybe for reasons to promote competition. At the beginning you had only a few root CA with very high prices. Now the prices are down because all CA can issue a certificate for anybody. If each CA would only be able to sign certificates for a specific part of the internet this competition would not be possible.

Such insecure initial design you have in various parts of the internet protocols and it is usually worked around by adding optional security, i.e. pinning for certificates, content security policy against cross site scripting etc. Of course, all of this is is just added optional security and thus rarely used. The general thinking is that it works without so why care.

Would it not be more secure that you designate which root certificate authorities are allowed & trusted to sign certificates for your domain name records for example via DNS SEC?

There are ideas to use it and in the area of mail security DANE is slowly gaining followers and there are also proposals to store SSH or other keys and certificates (or fingerprints) in DNS. The main problem is that one would need to first have DNSSec available everywhere before one could rely on DNSSec to deliver all these certificates. But for now only a small part of the internet is protected by DNSSec. Also lots of DNS resolvers don't deal with DNSSec at all or not properly and at the application level you usually have no access to the protection status of a DNS response too.

Similar DNS examples are also mail SPF records where you say which mail servers are allowed to send mail from your domain.

SPF or DKIM records are considered not that much security relevant and thus delivery of these records with unprotected plain DNS is considered acceptable. This would not be the case with certificates where you would need a response you can fully trust.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
4

Relying on DNSSEC would essentially amount to transferring our trust from the CA's to the registrars (e.g. firms like GoDaddy), the TLD's (e.g. VeriSign), and the root (e.g. ICANN). I'm not sure we can trust these entities any more than we can trust the CA's. See Moxie Marlinspike's blog post for a great write-up on this subject: http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authenticity

mti2935
  • 19,868
  • 2
  • 45
  • 64
0

You've hit on one of the fundamental problems with certificates. They are a form of authentication, but they are poor at authorization. I know who you are, but what are you allowed to sign? And do you and I agree on the definitions anyways?

Over time, various bits have been hacked into X.509. Bits represent whether you can sign code, encrypt over TLS, etc. But there's no notion of "scope". It's not like "I'm a CA, but I can only sign certificates for the example.com domain". Even then, there are implementation differences and interpretation differences.

One of the big problems is that X.509 muddled up authentication and authorization. The set of operations one can do (sign data, encrypt data, issue certificates, revoke certificates, etc.) is ill-defined. The possible restrictions (always, never, sometimes, with approval, etc.) are undefined. The scope of operations (limited to a domain, a sub domain, etc.) is ill-defined.

It's a 20-30 year old system that is sorta showing its age. But there's no easy fix.

Paco Hope
  • 401
  • 2
  • 2