Self-signed certificates in production point to a failure of SSL

I am realising that, although the problem that many Firefox users have with self-signed certificates points to a failure in software design (this is not a stab at Firefox, rather a testament to how difficult it is to design software to suit a diverse user base), it really points to a failure of SSL. Why do we have such large numbers of self-signed certificates in the first place? Why isn't everyone using valid certificates?

SSL is a great security protocol and a great success overall. Consider the following:

1. Hybrid protocol that, when properly implemented, offers security and performance at the same time.
2. Future-friendly design that allows ciphers and hashing techniques to be replaced as they begin to age
3. Can be applied to any communication protocol (well, almost any; and the problem will eventually be fixed).
4. Free.
5. Rock solid, as the designs are in the public and they have been thoroughly reviewed.

The catch is in the "properly implemented" part. SSL can give you security but only if you can build on top of an existing trust relationship. Most people don't really think about the underlying trust foundation because this is something normally handled by browser vendors when they accept to trust the root certificates of the established certificate authorities. By the time you open a browser you already trust a few dozen entities. They, in turn, extend their trust to cover the web sites you are visiting and everything seems great. Except that there are a few rough edges:

1. Using valid certificates is an optional step in the configuration of any web server. It requires knowledge, time and effort, and many people can't be bothered. There's also the overhead of required regular maintenance.
2. The cost model falls apart for very small entities, mostly because of the administrative overhead, but also also because of the additional cost of the certificate itself.

At first I thought the best thing to do would be to relax handling of invalid SSL certificates in browsers. After all—I thought—we don't really trust; most people don't check certificates anyway. We really care about transport security and not having our credit card details snapped while in transit. My idea was to simply ignore the fact that a certificate is self-signed. Perhaps use different colours to show the difference. I felt pretty good about that until I realised that would allow for unrestricted exploitation through man-in-the-middle (MITM) attacks. You see, the problem is that it is impossible to differentiate between a self-signed certificate and a MITM attack. It's not a problem of SSL or even the implementation. Oh, well, back to the drawing board. (Bruce Schneier recently wrote about MITM attacks: his post has a couple of very interesting stories and workarounds.)

The only thing I can think of that would help is raising awareness, and browser vendors seem to be doing that at the moment. Yes, there's a number of angry people, but I trust all the vendors will do the right thing—eventually. We should just be patient and wait for it to happen, while continuing to remind the vendors that security matters.

Comments

[David Trejo]

What if the generation of the ssl certs included a self-signage argument? Then perhaps the current system could work in concert with self-signed certs. oh...and you would get the pretty colors two if browsers responded to the argument as well.

On my end, I too have hit the wall of practicality when it comes to self-signed certs. WIth browsers like IE7 and FF3 not only displaying gigantic error messages, and FF's outright blockage of the site, it's gotten difficult for users to trust the sites. Sure we can get around that, but it does add to our already heavy workload and affects our budget.

[Eric]

Hello there,
I've been googling my question, and I ended up here. After browsing your site quickly, it seems you have a pretty strong grasp on what you're talking about in this post, and therefore I pose my quick question to you..

Here's my situation, I'm writing some web software (in LAMP, php4 and apache4), and it contains some sensitive information. Not sensitive as in credit card numbers or social security numbers, but some account numbers and email addresses etc that I wouldnt want people to be able to sniff out. This application will be for my and a select few people's usage only, but it will reside on the web.

So my question is this, given that I don't really feel like spending 60 or whatever dollars for a valid SSL for something that I don't really feel it is necessary for, would a self-signed certificate be "OK" in my particular instance? Would my self-signed cert encrypt the data from this site all the same as a regular valid certificate would? I have no problem telling the few people that will be using the site to "do this, do that, click this, add this, click that" in order to bypass any browser settings that may limit them from using the site (since ssl will be forced), but i want to make sure that my data is actually protected with a self-signed certificate, and not just a facade, as it were.

Thanks for any help you can provide!

[Ivan Ristić]

Hi Eric,

A self-signed certificate provides no protection whatsoever at present. Using a man in the middle attack (MITM), an well-positioned attacker can reroute communication intended for your site to go through him, and not only gain access to the information exchanged between the site and the users, but also perform arbitrary actions (on your site) on behalf of the users. This is especially true when a site is accessed over open Wi-Fi networks, which is very common nowadays. Such attacks are routinely being carried out.

I would suggest that you purchase one of the cheap SSL certificates. I've recently purchased one for less than $10 (per year), and I've seen plenty of places where they cost less than $20. There's even one company that gives them away for free with a domain name purchase.