Chris's Wiki :: blog/web/SelfSignedServerProblems

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

November 30, 2008

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.)

Comments on this page:

From 24.18.159.156 at 2008-11-30 12:09:51:

PKI-signed certificates are infeasible in a lot of circumstances, like in embedded devices.

When you're using a WiFi connection to sign in to the web interface of a local device (like the router!), sniffing can be insanely easy, in a way that MITM attacks have never been.
— blasdelf@gmail

From 83.145.208.36 at 2008-11-30 16:01:23:

The above comment captures what I've been meaning to mention many times while reading your thoughts about self-signed certificates.

Let me put this in two provocative remarks.

If you deal with many embedded devices in untrusted local area networks, HTTPS/SSL with self-signed certificates is fully acceptable (and often the only) way to provide at least some encryption as well as trust. (And if you do this for work, you really don't want Firefox3 to display those morbid popups.) Or as noted above, do you really need to pay some certificate authority in order (in the future?) to use, say, EAP-TLS et cetera?

Secondly, for the sake of the argument, I am writing this from a country whose internet traffic goes via another country that monitors all cross-border traffic. This is a good example why I think there is a need for the "opportunistic encryption", providing at least some sort of a shield for the commen men, in the year 1984.

By cks at 2008-11-30 17:42:05:

I totally agree on the embedded devices issue; as I've said in passing, I could never use a browser that doesn't allow overriding certificate issues, because we have too many things that ship from vendors with certificates that are either self-signed or have mismatched 'host names' (often because the device doesn't know its name until its actually installed, if then). And I'm no fan of the Firefox 3 approach; I think its handling of SSL problems is both ineffectual and wrong-headed.

I would really like opportunistic encryption for web browsing, and remain utterly irritated that SSL was not designed to enable it from the start. But I think it would do significant damage to whatever security we have now if browsers silently allowed https URLs to just get opportunistic encryption, not actual security.

(And on a practical basis I don't think we're losing anything by not trying to do it. You can already get encryption with any website that's currently offering SSL, and any website not currently offering SSL would have to change its configuration however the opportunistic encryption was implemented. So I think it should be implemented reasonable well.)

Written on 30 November 2008.

«	Good editors aren't better or worse, just different

My view on vi and vim (and nvi et al)