The TLS (also known by its predecessor’s name, SSL) encryption protocol is in effect the way to provide strong encryption of Web authentication. While other options for encrypted authentication are available, such as HTTP digest authentication, they tend to use weaker schemes. The biggest problem with HTTP digest authentication, for instance, is the fact that it provides no mechanism for server identify verification. This makes it particularly vulnerable to man in the middle attacks.
Unfortunately, the TLS protocol is designed specifically with certificate authority PKI in mind as its method of server verification. This certificate system is a technically involved process that relies on trust of a third-party certificate authorization for server verification, akin in some respects to the web of trust model employed by OpenPGP public key encryption, but with more bureaucracy involved. The major point of departure from the web of trust is its breaking point, however: instead of relying on the judgment of people you personally choose to trust, you are instead expected to rely on self-serving commercial claims of authority to tell you who you can and cannot trust.
This CA system is baked into TLS and the HTTPS protocol used by browsers, such that even if your intent is to make use of a distributed correlative verification system like that offered by Perspectives or a web of trust adaptation such as that offered by Monkeysphere, you still need to go through the rigmarole of setting up your system as if you intend to use the CA PKI instead. Self-signed certificates are, outside of the payment requirements, essentially no easier to set up than CA-signed certificates. The static IP address requirements of traditional TLS certification are not relieved by self-signing your certificates, either — a technical limitation that does not apply to other public key encryption protocols like OpenPGP.
What’s wrong with TLS?
The problems with the TLS-based PKI are many, for many circumstances. One key problem is its unsuitability for simple, low-resource websites that require secure authentication but are not supported by a commercial model or deep-pockets hobbyist. Shared hosting, what amounts to the cheap way to provide a “real” website, presents some unpleasant barriers to the use of TLS protected authentication too (i.e., shared IP addresses). These difficulties in no way eliminate the need for authentication protected by server verification and strong encryption, of course.
This is in theory a solved problem. OpenPGP is an encryption protocol whose basic structure was designed by cypherpunk hero Phil Zimmerman about two decades ago. The use of a simple public key for half of the encryption/decryption process allows for an extremely flexible basis for out-of-band verification of the key’s association with a given individual, organization, or site. Its publication via any of a wide range of distribution mechanisms can be used to offer outside verification. This could include the web of trust model that serves as the default key verification process for traditional OpenPGP, and the distributed system provided by Perspectives.
Theory and practice are rarely identical, and in practice this is not a solved problem at all. The fact of the matter is that TLS is so widely regarded as the only choice that there has been no serious movement on the development of alternatives — even superior alternatives using already extant technologies. There is an obvious opportunity for an alternative that does not rely on corporate sponsorship for basic implementation to build visibility and mindshare, and without initially challenging the CA-based PKI for market share. All it would take is a pair of simple implementations of Web authentication to cover essentially all standard shared hosting cases where TLS is an unreasonable burden, in each case using an extant public key encryption protocol such as OpenPGP: a CGI implementation, and a PHP implementation. Given even moderate success, other implementations would soon follow — Ruby on Rails, Django, CMS plug-ins, and so on.
Unfortunately, encryption implementations are hard to get right. A truly simple implementation of an OpenPGP Web authentication scheme would depend on assumptions about the kind of software running on the server, and would not be particularly portable — or would depend on OpenPGP implementations being available in whatever language the Web developer is using on the server side. Either is a difficult proposition when dealing with shared hosting, where the Web developer has little or no control over what basic software is installed on the system, while the encryption libraries for most server side languages commonly used on shared hosting rely on the same outside tools (often GnuPG) for parts of their OpenPGP support.
Let us not forget the difficulty of dealing with the client. Modern, feature rich browsers have all come to support TLS encryption via the HTTPS URI schema. They do not, however, include built-in support for Web authentication via OpenPGP. Browsers with robust extension systems may offer a relatively easy way to attach such functionality to the browser, at least in some cases, but the extensions need to be written — and doing so with ease would then depend on languages or discrete software installed on the client system, which is even less reliable a basis for authentication system dependency than the availability of software on shared hosting servers.
Challenges for an OpenPGP alternative
Here, at last, we find out why there is no OpenPGP-based — or similarly stand-alone public key encryption — alternative to TLS. A grass roots effort, such as could be provided by the open source development community, could conceivably provide the entire infrastructure needed to kick off such a bottom-up challenge to the practical hegemony of CA-based PKI in Web encryption. It is difficult to foresee this occurring without some forward thinking graduate student or major corporate sponsor getting things rolling, however, because of the sheer number of different pieces of a new infrastructure for Web authentication that would need to be built. Worse, even if such an open source system was built, it would not be unreasonable to lay even money it would be released under a license (probably copyleft) that would actually discourage use of the code in some circumstances, thus limiting its initial adoption. This does not even include the requirement for a standardized, easy to use out-of-band key verification system, which is not technically required for the system to work but would need to arise before widespread popularity amongst the technically uninclined would be particularly likely.
Despite all this, such an approach seems to be the single most likely, easiest way to provide a more “democratic” alternative to TLS, initially for authentication at least — and perhaps eventually for full-session encryption.
Note that while OpenPGP provided the basic example for this article, the SSH protocol would serve similarly well in this role.