Wandering Thoughts archives

Server problems caused by 'transparent' self-signed SSL certificates

One of the issues with allowing self-signed SSL certificates to be automatically used for transparent encryption over https URLs is the problems that they cause for server-side applications.

Right now, a server-side program that care can more or less assume that a SSL-encrypted connection means either that it is securely talking to the real end user's machine or that the end user has been actively compromised (which it can't do anything about). It may thus use things like 'you can only talk to this service over https' as a reasonable security precaution, one that means something.

If you allow self-signed SSL certificates to be used transparently for encryption in https URLs, you enable relatively trivial man in the middle attacks. This negates all of the security properties of SSL connections. Because the browser knows what level of security the certificate it accepted had, browsers can recognize this and lie to things like Javascript so that nothing thinks it's getting more security than it actually is.

However, the web server does not know and cannot know this information, since it has no way of finding out if it is talking to the real end machine or to a man in the middle. As such, server side applications can no longer assume that a https URL and a SSL connection means actual security; it might be secure and it might not be, and they can't tell the difference. This leaves them with no way to require something approximating actual security from clients, and it breaks current applications (to the extent that they assume that SSL means security).

(Server side applications cannot do things like feed Javascript to the client browser to see if it is really connecting directly to them, because the man in the middle can rewrite that Javascript on the fly.)

(In theory the one way out of this is to require everything to have client side certificates. However, I do not believe that this is any more practical than trying to make all server side applications instantly give up any 'SSL means security' beliefs that they may have.)

The practical insecurity of self-signed SSL certificates on the web

Here is a modest suggestion from the devil's advocate: web browsers should forbid self-signed SSL certificate entirely, with no 'no, really, let me through' button, option, or extended dialog. They should do this because in practice and in general there is no way to make self-signed SSL certificates at all secure.

Self-signed certificates are insecure in general unless you really truly know what you are doing. Most users do not know what they are doing in this sense, and for sensible reasons will pretty much ignore any warnings you throw up to try to teach them and will blindly click on any button required to make things get out of their way. In the real, pragmatic world the results of this are, unfortunately, predictable and explosive.

Given my previous views on this I don't really like this. But it seems quite hard to allow for any quiet implicit use of self-signed certificates for things like opportunistic encryption, and it's also clear that if you give the general user population something explosive, people are going to blow themselves up through accident and ignorance. Ignoring this reality is just as wrong as ignoring reality in pursuit of mathematically perfect security, and for the same reason.

(You can argue that only a few people will blow themselves up this way and that most people will read the alerts and save themselves. I think this is totally wrong.)

Note that I don't necessarily agree with this; I just think that it's a plausible argument. Even if it's plausible it may not be practical, since by now there are enough vendor-supplied things out there in the field with malformed or self-signed SSL certificates that a browser that could not accept them would be pretty crippled (certainly I could never use it).

(Making self-signed certificates work only if you turn on a secret preference doesn't work in the real world; someone writes up the secret preference, and soon the search engine hits roll in and everyone knows that to get browser X to work right and get out of your way you do this magic thing and then click through the dialog boxes just like you used to. Down that road is Firefox 3.)

Another attempt to split SSL into encryption and trust

From one perspective, ideally SSL would be split apart into encryption and trust, with the goal of letting you have encryption without trust. In theory you could achieve this with a different handling of https, but lately I have come to think that the user expectation problems of such a solution are insurmountable at this point; too many people just know what https in URLs means for its meaning to change (in a subtle way).

(My personal feeling is that it is pointless and even undesirable to go the other way and try to have trust without encryption.)

So, let's take as given an axiom: if it has https: visible in the URL it must have trust, not just encryption. Thus, however a split works, the SSL encryption must appear to use a http: URL as far as the user sees (and as far as Javascript sees). While SSL is client-initiated and thus servers could accept it on regular HTTP ports, the client browser can't just blindly try it with strange web servers, since it would be a protocol error (and make people unhappy when it showed up in their logs).

(The client browser cannot just quietly try making an https request instead of an http one, because even if it exists there's no certainty that a server's https website supports the same URLs with the same meanings as the http website does.)

If we're willing to accept that the first HTTP request to a web server won't be encrypted, we can have the server signal clients that it supports direct SSL on the normal HTTP port by adding an appropriate new HTTP header to its reply. Cooperative clients would then do SSL on subsequent connections. (Clients that want all real requests to a new web server to be encrypted if possible can try a small dummy request, perhaps 'HEAD /', before their first real request.)

One downside of this is that it would probably have terrible effects on the effectiveness of any intermediate caching proxies, especially transparent ones (at least until the proxies were updated to understand the scheme and either strip out the header or implement the scheme).

(Properly implemented it should not malfunction in the presence of an uncooperative proxy; the client browser would try once to do 'SSL over HTTP', fail, and fall back to ordinary HTTP.)