Trusting SSL and the Trust Chain

Question

As we all know, when an SSL Certificate is assigned, there is a trust chain that is created for verify everyone from the Certificate Authority to the actual website's SSL Certificate.

Thanks to a good discussion with a security expert, I am lead to believe that this trust chain is flawed by the way it is done. After so long in the chain, it seems like you are just blindly trusting everyone that assigns/controls the certificate, even the Certificate Authority.

Is this method blind trusting the Certificate Authorities, Root Authorities, and everyone that processes the SSL Certificate?

I do see this as a major flaw in the system which we hold dear and use.

Answer 1

The chain is not verified "by itself". A given system (say, a Web browser) will consider a server's certificate as valid because it could build a valid chain (with all signatures corrects and matching names and all the rules of X.509) which ends with the certificate to validate (the server's certificate), and starting with a root CA that the client already has.

Signatures don't create trust, they transport trust. It still has to start somewhere. Each client (either in the browser or in the OS itself) comes with a list of "trusted CA": these are the public keys and names of some entities which are deemed "trustworthy" (you did not choose them yourself; Microsoft did that for you; but, anyway, as long as you use Microsoft's software you are trusting Microsoft for not playing nasty games on you). The root CA are "trustworthy" if you trust them for not issuing certificates with fake information: when a CA issues (sign) a certificate for some entity E, it is supposed to make sure that the public key that the CA puts in that certificate, along with E's name, is really owned by E. Similarly, when a root CA delegates its power to another CA (then called intermediate CA or sub CA), it makes sure (through audits and binding contracts) that the sub CA is indeed trustworthy, in that it will apply the same rules.

That's the concept of a Public Key Infrastructure: as a client, you know a priori a handful of public keys owned by trusted CA, and you implicitly trust everything that these CA signs. The certificates assume a tree-like structure, with the root CA as, well, the tree root (hence the name), and the end-entity (SSL servers) certificates as leaves. A certificate chain is really a path from the root to a given leaf.

If a root or intermediate CA becomes untrustworthy, for instance because it was hacked and issued a fake certificate (a wrong association between name and public key), then the recovery entails severing the bad branch, a process known as revocation. In practice this does not occur often for big commercial CA (the ones that are trusted by default in Windows or Firefox); say about once a year. E.g. that one occurred a few days ago, and both revocation and a fail-safe patch from Microsoft block any attempted usage of the rogue certificate. In practice, normal attackers (say, for phishing purposes) don't bother obtaining "valid" certificates for their fake servers.

Answer 2

I would not call it blind trusting, but yes - you rely on the trustworthiness of the root certificate and all the intermediate authorities on the way depending on the implementation and configuration.

A website's certificate is verified with a CA. In order to make sure this CA is indeed the actual CA you intend to trust, you can verify its own certificate with another CA above it in the hierarchy... this repeats itself until your reach what is called a root certificate. This certificate is validated by your software which has a list of root certificates it trusts. This can be managed by the OS or by the application itself.

Hence eventually all your security relies on this path from the root certificate all the way down.

Attack vectors include:

An attacker manages to install a malicious root certificate on your PC it is game over.

An attacker manages to fool one of the CA's or exploit a vulnerability and own a CA

Answer 3

There are lots of flaws with the current PKI, and trust chain is one of them, but not the only one and not in all cases.

• Each browser/OS comes with lots of CAs and the trust is enabled by default. So once you get the browser you implicitly trust all these CAs for your communication. You need to explicitly disable trust settings if you want to control whom you trust.
• Each CA can create any certificate they want, e.g. they can create a certificate for google.com even if there is already such a certificate from another CA. And the browser will accept these certificates unless it uses certificate pinning or similar techniques.
• Each CA can create an unlimited number of sub-CAs.
• Each sub-CA has the same unlimited rights as its parent-CA, e.g. can create any certificates, including sub-sub-CAs. These sub-sub-CA again have the same rights etc. This means you have to compromise only a single one of the thousands CAs/sub-CAs/sub-sub-CAs etc to get any certificate you want.
• There is currently no control which CA/sub-CA issued which certificates or sub-CAs, so it is tempting to sell such unlimited sub-CAs to government and other institutions, which can use them for transparent man-in-the-middle attacks.

So, the trust chain is part of the problem, because you cannot limit the abilities of a sub-CA. If the sub-CA is controlled by a different party then the parent CA it also increases the risk of compromise.

But, sub-CAs can also be used for better risk control. If the owner of a root-CA creates a controlled amount of short-lived sub-CAs from the long-lived root-CA and uses these sub-CAs to sign, (s)he can lock the secret key for the root-CA in a very safe place until the short-lived sub-CAs need to be renewed, so only the less valuable sub-CAs might be compromised. And, you can revoke the certificate for a sub-CA (at least in theory), but for revoking the root-CA you would need to update all browsers/OS.