Fragments

PKI Hell Part 1: Back to Basics

July 23rd, 2008 | by Jan Bervar |

For a number of years now, it has been unfashionable to criticize the condition of PKI and X.509. We use a subset of these standards daily to surf the web (HTTPS), exchange email (S/MIME, SMTPS, etc.), and so forth. Some pains of PKI are well documented (see Peter Gutmann’s “Everything You Never Wanted To Know About PKI But Have Been Forced To Find Out“), and the horrors and deficiencies of our current worldwide PKI deployment for web servers and browsers are known to most security folks.

Whereas many tech people believe that the devil is in the details, I think that we – IT (security) practitioners – still don’t get the basics right most of the time. Today, let me start with some of that basic stuff, and we’ll progress to the “details” later on.

In most of the PKI-related projects in which I participate, most people who need to integrate their components with PKI-enabled authentication and encryption seem to have a poor grasp of the cryptographic basics underlying PKI. The biggest culprits of all seem to be the following notions, deeply ingrained in the minds of IT professionals:

• The notion that an X.509 certificate (and not the associated private key) is secret information, and that the words “certificate” and “private key” are completely interchangeable
• The perception that certificates (i.e., the format, not the trust chain) somehow guarantee public key authenticity
• The perception that some encryption bootstrapped by PKI-based authentication is strong, even though certificates used for that authentication are not necessarily trusted

The public key authenticity issue seems to be the most dangerous, as many things depend on it. I am writing this article because two recent posts on Slashdot (“When Is a Self-Signed SSL Certificate Acceptable?” and “What Would It Take To Have Open CA Authorities?“) clearly demonstrate at least some of these issues, based on user comments. To make the story worse, vendors that develop security products are subject to the same misconceptions. Over the years, I have reported three public key verification problems in Cisco products (MARS/ASDM, IDS MC), all of which were fixed promptly. These products accepted the public keys of remote peers without any validation, allowing trivial active MITM attacks to break their cryptographically protected sessions in no time. I expect similar issues to be discovered with many other products in the industry.

By the way, some of these issues persist inside shipping products, unknown to most users. The Cisco IOS SSH client (except on IOS XR) still has no way of verifying the server’s public key, making the entire IOS SSH client implementation useless for serious users. Every time you connect using SSH from a router to a SSH server, the client blindly trusts the public key it has received over the network, making it easy prey to MITM attacks. Therefore, I obviously advise against using the IOS SSH client, unless you are comfortable with Telnet-like security functionality.

In part 2 of this article, I will talk more about self-signed certs, and how browsers are evolving (some will say regressing) to make people use them in a better way.