How self-signed certificates are a problem for browsers

October 17, 2008

I was a little harsh on Firefox 3's handling of self-signed SSL certificates in the last entry, and in fairness I need to say that this is a genuinely hard problem for browsers, at least from a security perspective. Let us talk about just how this is so.

First, let us start with my previous basic model of how https could work. Browsers always use SSL if possible, and they protect against straightforward man in the middle attacks by remembering the SSL certificate they saw last time, or at least how strong it was, and complaining loudly if the SSL certificate is weaker. Call this the downgrade problem, and I believe that it's pretty solved.

(What does 'solved' here mean? To me, it means that you can accept self-signed SSL certificates while giving users the security that they think they're getting.)

This still leaves what I will call the initial connection problem. Suppose that the user types a https URL in that resolves to a site with a self-signed certificate, and the web browser has no SSL certificate information for the site on file; what do you do? Since the user explicitly typed in the https bit, they may well expect that you will give them full SSL protection, including genuine identity verification.

(Before people bring up SSH's handling of this, let us admit that only the paranoid actually validate those SSH host key signatures that OpenSSH tells you about; everyone else just says 'yes' automatically.)

One might hope that this was an uncommon case, but consider how often people empty their browser's caches for various reasons. And privacy concerns mean that if the user selects 'forget everything', we do need to forget the remembered SSL certificate information; clever hashing can't save us.

A related risk is using other people's computers, including public computers, and connecting to https sites; here an attacker might have preloaded their man in the middle self-signed certificates as the website's certificate, so the browser would see a self-signed certificate that matched the one on file. The counter argument here is that in practice there are lots of far worse things that can be done to public machines.


Comments on this page:

From 84.14.183.246 at 2008-10-17 04:10:32:

Hi Chris,

I'm no expert in security, but for the initial connection, maybe the browser could use a DNS query to get a TXT record containing the public key (or its fingerprint) of the certificate, thus validating that the self-signed certificate is indeed coming from the domain it asserts ?

Of course if the DNS resolution can't be trusted (through things like cache poisoning), then this fails. But then again, DNS attacks are already one vector of man-in-the-middle attack, which is precisely the thing we decide to ignore by using self-signed certificates. So if this is the kind of thing to fear, nothing short a full blown CA certificate can help.

What's interesting with this kind of DNS verification scheme is that nothing changes on the SSL side, and the browser-side code would be pretty simple (one more DNS lookup only the first time an unknown self-signed TLS certificate is seen).

From the perspective of the final user, there could be three levels of security : unverified/unsecure (=TLS with unverified self-signed certificate), low-grade security (= TLS with self-signed certificate validated by DNS) and high-grade security (=TLS with CA-issued certificate).

Regards,

Nicolas Lehuen <nicolas at lehuen dot com>, http://nicolas.lehuen.com/

By cks at 2008-10-17 12:11:52:

The real problem is one of satisfying the user's perception of how much security they're getting, and (if necessary and possible) changing those perceptions. (I didn't say this very well in the original entry.)

Browsers can introduce technical solutions like multiple levels of SSL security, but if they surprise users by delivering less security than the user is expecting they've failed in practice and haven't solved the problem. I'm not convinced that it's possible to satisfy user security expectations while still more or less automatically accepting self-signed SSL certificates (although it's possible to do better than Firefox 3 does).

Changing user perceptions is of course a hard problem, which is one reason that browsers opt for 'security' through excessive paranoia; if you are excessively paranoid, at least no one can argue that you are fooling the users and giving them less security than they expect. (And of course there are all sorts of fun arguments about how much security our hypothetical users are actually expecting when they do something.)

Written on 17 October 2008.
« Why Firefox 3's handling of self-signed SSL certificates is wrong
More on Firefox 3's handling of self-signed SSL certificates »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Oct 17 02:17:10 2008
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.