PKI Hell, Part 3: Non-global PKIs and Some PKI Humor

August 7th, 2008 | by Jan Bervar |

In parts 1 and 2 of this series I bashed some aspects of the current state of real-life PKI implementations, the “global PKI,” and the use of self-signed certificates. What we have left are PKIs that are not global, nor do they use self-signed certificates. I am talking about private PKIs and public PKIs that are not part of the “global PKI” (i.e., their CAs’ public keys are not embedded in your OS or browser).

Such PKIs are typically used in the following ways:

  • Internally by companies (often to chase the Holy Grail of single sign-on). For instance, NIL uses a single private PKI for Lotus Notes, internal web servers, remote-access VPN, wireless and LAN 802.1x authentication.
  • Externally by companies to provide a key management service for externally facing applications (extranets, electronic banking, and so on).
  • Offered as a managed PKI service that is not part of the “global PKI” (i.e., “untrusted roots”).

Using these PKIs is just fine and dandy, if you do the dirty details right. Where most organizations fail is in recognizing that PKI users must somehow obtain an authentic copy of the CA’s public key. This has to be done over a sufficiently secure channel – either out-of-band (paper mail, physical contact with the user), or through an established cryptographic channel – to ensure that the CA’s public key is not replaced in transit with a rogue key of the attacker. Sounds simple, but many PKIs fall short in this regard.

Some years ago I had an incident with my (former) bank. The bank was providing an electronic banking service in which the server and the client (me) were authenticated using private/public keys from the bank’s private PKI. After a year of using the e-banking service, I reinstalled the OS on my home PC, and backed up only my own private/public key and certificate. I forgot to back up the bank’s CA certificate, which is used to verify any other certificate (including the bank server certificate) of the bank’s PKI.

When I tried to connect to the e-banking site, the well-known warning about an untrusted server certificate popped up. I knew immediately what was wrong, and decided to phone the bank’s help desk to verify that this certificate and the associated CA certificate were authentic. I wanted the bank to read the CA certificate’s fingerprint over the phone, so I could verify it against the CA certificate I obtained over the network. To make a long story short, the bank’s help desk did the following:

  1. They insisted that I should blindly accept the certificate, although the certificate could not be verified.
  2. They repeatedly refused to give me the CA cert’s fingerprint, as though it was super-secret information.
  3. They insisted that the server or CA certificate I received over the network was authentic, because it contained the bank’s name. (I did not laugh at this point, although I should have… and very hard.)
  4. They finally hung up on me (literally!) and when I complained to their managers via email, they sent me the CA cert inside cleartext email (i.e., again over an untrusted network).

After this incident, I switched banks immediately, as my e-banking contract held me liable for any fraudulent transactions associated with my account. If the bank cannot manage security properly, how can it push all liability to the end user? (On second – and cynical – thought, that may be exactly the reason for doing it.)

These days, my former bank – per my suggestion back then – offers its private CA certificate for download over an HTTPS connection, where the server that is used to download the CA cert has a certificate issued by one of the “global PKI” CAs. This technique at least allows users to have more assurance about the authenticity of the bank’s private CA cert.

A second story about untrusted roots is short, but sweet. The annual Slovenian Microsoft conference (NT konferenca) always provides a web site for people to register and review the conference schedule. Some years ago, the conference decided to “secure” the site by providing HTTPS access to its web server. The certificate used by the server was issued by a Slovenian PKI provider, whose CA’s certificate is not in the “global PKI” (i.e., embedded in your OS or browser). Naturally, most people who visited the site got the nasty warning that the server certificate could not be verified.

Microsoft’s response? A sentence on its web page: “Although you will receive a warning that the certificate of this server is not trusted, click OK and proceed. Your session will still be properly secured“. Apparently, it does not matter to whom you are talking, as you cannot authenticate the server; it might be an attacker doing a man-in-the-middle attack impersonating the server – exactly what SSL/TLS and server certificates are designed to prevent. To Microsoft, it only mattered that you had a “secure” session – but in the case of a man-in-the-middle attack, that is a secure session with the attacker.

Here is the original text for our Slovenian readers:

Coming up, practical PKI in Cisco IOS VPNs.

You must be logged in to post a comment.