Greetings. In http: Must Die! (and The Encryption Solution), I suggested an accelerated move toward the routine use of encrypted TLS/https: instead of unencrypted http: for Web communications.

An issue that cannot be ignored in this regard is the cost and logistics of server security certificates that are natively recognized by popular Web browsers.

Certificates are required to enable TLS encryption in these environments, of course. And while the marketplace for commercial certs is far more competitive now than it was just a few years ago, the cost and hassle factors associated with their purchase and renewal are very relevant, especially for larger sites with many operational server names and systems.

What isn't widely understood outside of the technical community is that "self-signed" certificates, which can be generated for free by anyone (and with essentially arbitrary expiration dates) can enable these cryptographic systems in a manner very similar to commercial certs. What self-signed certs typically won't provide is the same "web of trust" confirmation (via a widely recognized certificate authority) for the identity of a given site.

However, in a vast number of applications where absolute identity confirmation is not required (particularly when commerce is not involved), self-signed certificates are quite adequate. Yes, as I alluded to in my previous blog posting, there are man-in-the-middle attack issues associated with this approach, but in the context of many routine communications I don't feel that this is as high a priority concern as is getting some level of crypto going as soon as possible.

Given their significant capabilities, why then are self-signed certs primarily employed within organizations, but comparatively rarely for servers used by the public at large, even where identity confirmation is not a major issue?

A primary reason is that most Web browsers will present a rather alarming and somewhat confusing (for the typical user) alert as part of a self-signed certificate acceptance query dialogue. This tends to scare off many people unnecessarily, and makes self-signed certificate use in public contexts significantly problematic.

Security purists may bristle at what I'm going to say next, but so be it. I believe that we should strongly consider something of a paradigm shift in the manner of browsers' handling of self-signed certificates, at the user's option.

When a browser user reaches a site with a self-signed certificate, they would be presented with a dialogue similar to that now displayed, but with additional, clear, explanatory text regarding self-signed certificates and their capabilities/limitations. The user would also be offered the opportunity to not only accept this particular cert, but also to optionally accept future self-signed certs without additional dialogues (this option could also be enabled or disabled via browser preference settings).

If the user declined this option, the browser would continue to treat self-signed certs in the traditional manner. If the option were accepted, future self-signed certs would not trigger the query dialogue.

In either case, the use of a self-signed certificate would ideally cause the appearance throughout that session of an appropriate unobtrusive but clearly visible "self-signed cert" notification message or icon. I would also recommend that the browser URL address bar change to a unique color (e.g. light blue or some other acceptable choice) to indicate a self-signed certificate in use.

There are obviously significant security ramifications to this proposal to be carefully analyzed, and a range of variations in the ways that something along these lines might be implemented.

But I hope that this discussion helps to stimulate explorations regarding the possible desirability and practicality of much larger scale use of self-signed certificates on the Internet, particularly to encourage the transition of routine Web browsing to an encrypted environment.

--Lauren--