William Lachance

After announcing Pathfinder a week or so ago, it occurred to me that most people might not know what it's good for (or at least the subtleties thereof). I certainly wouldn't have before I started working on this project, and the information on its more esoteric features is sort of dispersed across the Internet (if available at all). I figured I might as well try to help this situation (as well as Pathfinder's prospects for world domination?) by writing a bit about what it does and in what circumstances it might be useful.

Let's start at the beginning: certificates. An X.509 certificate is a token asserting identity (and various properties corresponding to that identity). At minimum, such a certificate contains an RSA public key, a subject name (who this certificate represents), and an authority name (who's vouching for the authenticity and/or trustworthiness of this certificate by signing it with its RSA key). That's really only the beginning though: an X.509 certificate can contain lots of other stuff corresponding to the identity of its holder: more on that later.

When an SSL connection is established (the most common example of this is connecting to a website over https in Mozilla or IE), these certificates are exchanged between server and client. In most software these days, only the client does any kind of validation of the certificate provided by the server: specifically, it will check the certificate to see that it signed by a certificate in a local "trusted" store (Mozilla and IE provide a trusted store composed of various certificate authorities by default). If so, we proceed with a Diffie-Hellman key exchange using the RSA keys in the client and server certificates and then proceed exchanging data. If not, well... that's up to the application. Web browsers usually pop up a warning that most people click through and ignore (an oft-discussed issue in usability circles: see here, for example).

Although uncommon, it is within the perogative of the server side of the connection to insist that the client provide a certificate when the connection is established, and to reject the client if this certificate is not within its trust store. This is the sort of thing you'd use if you're really paranoid about who you want to allow to (for example) connect to your super-secure web site.

When I talk about verifying signatures, I'm really referring to something broader called "path validation". That is to say, given a sequence of certificates 1..N (where 1 is ultimately trusted), is each certificate signed by the previous one? In the basic cases we've been talking about, there's only two certificates in the path under consideration, and we're only talking about verifying signatures. Validation can get much more complicated and paranoid than this, for those who have higher expectations regarding security. RFC3280 has all the details, but to name just a few things:

• Certificate revocation lists (CRLs): A certificate is supposed to provide a set of CRL distribution points, which tells you where to find a certificate revocation list which indicates (signed by the signer of the certificate) whether or not a certificate has been revoked. This gives you added confidence that a certificate hasn't been compromised.
• Chains of trust: A certificate may be signed by a CA certificate which is not in the trust store, but which is in turn signed by a CA certificate which is in the trust store. This information may be looked up by chasing the AIA (authority information access) field of the certificate which commonly points to an LDAP and/or HTTP URI.
• Bridged trust: Two certificate authorities can elect to cross-sign each other over a PKI bridge. This further reduces the extent to which it is necessary to ultimately trust CA certificates: you can just elect to trust the CA certificates in (for example) your organization, and the appropriate software can validate a path that goes from the client certificate to your CA through a series of "bridge" certificates (the trust in which can easily be revoked, if required).
• Policies constraints: You can insist that a certificate conform to certain user-defined policies in validation.

Needless to say, writing the code to do all of this correctly is rather difficult and, moreover, goes rather beyond the scope of a library like OpenSSL when it comes to chasing down CRL and chains of trust over the Internet. Pathfinder centralizes handling all of these things in a single daemon (accessible from the callback that libnss and OpenSSL use when initializing an SSL connection), making it easier to write and deploy software in a Linux/Unix environment which imposes the stricter requirements on certificate validity that I describe above. At least at first, I only expect it to be useful in certain niche cases with complicated requirements (most likely mail and web servers that are expected to traffic in sensitive information), but perhaps eventually we might see this sort of thing in wider deployment, making the Internet a safer place for everyone. One can dream, anyway...

Oh yeah, did I mention that Pathfinder uses D-Bus? Look: shiny thing!

What I've been working on

For the past while, I've been telling people that I've been working on some "security software" using WvStreams. Unfortunately, I couldn't say exactly what at the time. But that's all over now. Allow me to introduce PathFinder, the next-generation solution for certificate path validation. To my knowledge, Pathfinder is the first open source product which can perform RFC3280-compliant validation and discovery, downloading certificates and CRLs as necessary.

Best of all, getting access to this functionality is a simple matter of sending the certificate and a few parameters over D-Bus, so it should be easy for 3rd party applications to adopt. Sample code for using PathFinder from OpenSSL and Netscape Security Services is provided in the source distribution. The opportunities that this presents are exciting (at least one is already in the pipeline).

Special thanks to Carillon for sponsoring this project and the associated improvements to WvStreams' certificate and CRL APIs.

A note on WvStreams

WvStreams 4.4 is available now.

Over the past few years, some of us have become quite enamoured with WvStreams and how easy it makes it to write high-performance network applications in C++. But with the closure of the Montreal office of NITI^[1] in December 2006 and the associated departure of most of its original developers, I was uncertain about its future.

Who would have thought that, slightly more than half a year later, we'd see two releases, a vibrant community form around the library, and several exciting new projects? WvStreams certainly isn't the solution to every problem, but it does seem to be finding its niche. I'm hoping that it will eventually evolve into something like the Twisted of the C++ programming world.

^[1] The original corporate patron of WvStreams.