Fragments

PKI Hell, Part 2: We Have Met the Third Party and It is Us

July 28th, 2008 | by Jan Bervar |

In part 1 of this series, I started laying out what I perceive to be the basic problems of how certificates and PKI are (ab)used today, especially in Internet applications. Today, I want to take things a step further and discuss self-signed certificates and how browsers’ user interfaces have handled them over time.

With “global PKI” certificates, one of the root certificate authorities (CAs) - whose public keys used to verify certificate signatures are embedded inside your OS or browser - issues a certificate, based on some identity verification method ranging from domain ownership to supplying substantial paperwork for Extended Validation certificates. By using the root CA as a trusted third party, you choose to trust that it will not issue certificates to its customers without proper authentication. Although the term “global PKI” may be misleading, this is the closest thing to a global PKI that we have available today.

With self-signed certificates, an entity signs its public key with its own private key - in essence, acting as both a CA and a certificate holder using the same public/private key pair. In order for another entity to verify the authenticity of the certificate (and the embedded public key), you need the public key of the signer - which is the certificate owner itself. This is a chicken-and-egg problem and obviously cannot be resolved automatically. That is why a browser will throw some sort of an exception and expect the user to resolve the situation if the certificate signer’s signature cannot be verified.

To accept a certificate whose signature could not be verified, browsers historically have displayed a warning that could be dismissed easily by a user. Moreover, these browser warnings had several problems:

• The warning was not explained intuitively. I remember Netscape browsers suggesting to users that it was *unlikely* that something was really wrong with the certificate, even though the certificate could not be verified.
• The text was not specific enough. A whole host of certificate issues - from name mismatches and expired certs to unverifiable certs - were presented using the same user interface, although the severity of these issues is not exactly comparable.
• The certificate warning was too similar to other warnings. It sounded much like “Do you want scripts to run? Do you want to submit information to the Internet?” and so on, leading users to become conditioned to click on “Yes” to bypass such messages.

Internet Explorer 7 first broke this tradition by throwing a full-page error when a certificate problem was encountered, and encouraging users NOT to proceed with the session. Firefox 3 is even more fascist, requiring you to click around quite a lot before accepting a questionable cert. There was a whole lot of uproar because of such (especially the Firefox 3) behavior, with most users seeing this as a direct attack against people who do not want to join the “global PKI” with their Internet applications.

The complainers are dead wrong. These browsers are not trying to make it more difficult to use sites that are not part of the global PKI. Rather, these browsers are trying to teach users a lesson: it is not good to use certificates that cannot be verified automatically, as these certificates provide no authenticity assurance at all, and by accepting them, you are negating all subsequent SSL/TLS security features (encryption, integrity, …), as these features rely squarely on the initial authentication.

Now, I am not saying that self-signed certs are all bad. You can happily use self-signed certs *as long you can ensure that the self-signed certificate is authentic*. You can do this in two ways:

• By manually installing a trusted local copy of the self-signed certificate inside your OS/browser. For example, you can do that by visiting your self-signed site over a trusted network, and storing the self-signed certificate in your local cert store.;
• By visiting your self-signed site over an untrusted network, accepting the self-signed certificate, and storing the self-signed certificate in your local cert store. In performing this leap of faith, of course, you hope that nobody was performing a man-in-the-middle attack on you in this particular session when you stored the server’s self-signed cert locally; if this is true, you have a trusted, authentic public key of the server available locally and can authenticate the server properly from now on. If not, you may be subject to MITM for every connection you make to that server from now on.

Obviously, the first option is better, but you need initial access to a trusted network between you and the server - which is usually difficult if the network is the Internet. It is debatable whether the second approach is any better than doing the worst thing imaginable - manually accepting the self-signed cert every time you visit the site. A third option, obtaining the self-signed cert via an out-of-band channel (USB key, getting its fingerprint inside paper mail, etc.), is obviously less scalable and may be costly.

To sum up, it is indeed okay to use self-signed certificates, if certain conditions are met. The trouble is that these conditions are rarely met for Internet-facing applications accessed by users not under your control. How likely are users to access an application over a trusted channel initially? (Not very.) How likely are they to perform the described public key management in a consistent manner? (Not very.) What controls do we have available to detect when users make mistakes? (Few, or none in many cases.)

Part 3 of this series will discuss private CAs as an alternative for self-signed certs - and, boy, do I have some good war stories to tell you! After that, we will dive deep down into some Cisco-centric practical PKI-specific issues, and how best to avoid them.