Wandering Thoughts archives

HTTPS should remain genuinely optional on the web

I recently ran across Mozilla Bug 1041087 (via HN), which has the sort of harmless sound title of 'Switch generic icon to negative feedback for non-https sites'. Let me translate this to English: 'try to scare users if they're connecting to a non-https site'. For anyone who finds this attractive, let me say it flat out; this is a stupid idea on today's web.

(For the record, I don't think it's very likely that Mozilla will take this wishlist request seriously. I just think that there are people out there who wish that they would.)

I used to be very down on SSL Certificate Authorities, basically considering the whole thing a racket. It remains a racket but in today's environment of pervasive eavesdropping it is now a useful one; one might as well make the work of those eavesdroppers somewhat harder. I would be very enthusiastic for pervasive encryption if we could deploy that across the web.

Unfortunately we can't, exactly because of the SSL CA racket. Today having a SSL certificate means either scaring users and doing things that are terrible for security overall or being beholden to a SSL CA (and often although not always forking over money for this dubious privilege). Never mind the lack of true security due to the core SSL problem, this is not an attractive solution in general. Forcing mandatory HTTPS today means giving far too much power and influence to SSL CAs, often including the ability to turn off your website at their whim or mistake.

You might say that this proposal doesn't force mandatory HTTPS. That's disingenuous. Scaring users of a major browser when they visit a non-HTTPS site is effectively forcing HTTPS for the same reason that scary warnings about self-signed certificates force the use of official CA certificates. Very few websites can afford to scare users.

The time to force people towards HTTPS is when we've solved all of these problems. In other words, when absolutely any website can make itself a certificate and then securely advertise and use that certificate. We are nowhere near this ideal world in today's SSL CA environment (and we may or may not ever get there).

(By the way, I mean really mean any website here, including a hypothetical one run by anonymous people and hosted in some place either that no one likes or that generates a lot of fraud or both. There are a lot of proposals that basically work primarily for people in the West who are willing to be officially identified and can provide money; depart from this and you can find availability going downhill rapidly. Read up on the problems of genuine Nigerian entrepreneurs someday.)

Some consequences of widespread use of OCSP for HTTPS

OCSP is an attempt to solve some of the problems of certificate revocation. The simple version of how it works is that when your browser contacts a HTTPS website, it asks the issuer of the site's certificate if the certificate is both known and still valid. One important advantage of OCSP over CRLs that the CA now has an avenue to 'revoke' certificates that it doesn't know about. If the CA doesn't have a certificate in its database, it can assert 'unknown certificate' in reply to your query and the certificate doesn't work.

The straightforward implication of OCSP is that the CA knows that you're trying to talk to a particular website at a particular time. Often third parties can also know this, because OCSP queries may well be done over HTTP instead of HTTPS. OCSP stapling attempts to work around the privacy implications by having the website include a pre-signed, limited duration current attestation about their certificate from the CA, but it may not be widely supported.

(Website operators have to have software that supports OCSP stapling and specifically configure it. OCSP checking in general simply needs a field set in the certificate, which the CA generally forces on your SSL certificates if it supports OCSP.)

The less obvious implication of OCSP is that your CA can now turn off your HTTPS website any time it either wants to, is legally required to, or simply screws up something in its OCSP database. If your browser checks OCSP status and the OCSP server says 'I do not know this certificate', your browser is going to hard-fail the HTTPS connection. In fact it really has to, because this is exactly the response that it would get if the CA had been subverted into issuing an imposter certificate in some way that was off the books.

You may be saying 'a CA would never do this'. I regret to inform my readers that I've already seen this happen. The blunt fact is that keeping high volume services running is not trivial and systems suffer database glitches all the time. It's just that with OCSP someone else's service glitch can take down your website, my website, or in fact a whole lot of websites all at once.

As they say, this is not really a good way to run a railroad.

(See also Adam Langley on why revocation checking doesn't really help with security. This means that OCSP is both dangerous and significantly useless. Oh, and of course it often adds extra latency to your HTTPS connections since it needs to do extra requests to check the OCSP status.)

PS: note that OCSP stapling doesn't protect you from your CA here. It can protect you from temporary short-term glitches that fix themselves automatically (because you can just hold on to a valid OCSP response while the glitch fixes itself), but that's it. If the CA refuses to validate your certificate for long enough (either deliberately or through a long-term problem), your cached OCSP response expires and you're up the creek.

The core security problem of SSL on the web is too much trust

Every so often I'm surprised by what people don't already know (although I really shouldn't be). Today's surprise, due to Tim Bray's Blow up the Cert Business, is that people don't understand the core security problem with SSL on the web. I generally operate in an environment where this is common shared information, something that everyone just knows, but this is not the world in general.

So let's be explicit about what the real problem is:

The core security problem with SSL on the web is that your browser trusts a lot of Certificate Authorities and gives them power over any and all domains.

Your browser or operating system has a large list of built in CAs. Almost all of the time, SSL certificates signed by any of these authorities will be trusted to establish that you are talking to any random and arbitrary domain. There is no restriction on what domain names any of these CAs can issue valid certificates for and no mechanism that allows a domain to publish something that says 'no, no, wait, only trust SSL certificates for me that are signed by CA <X>'.

(Google has added special magic to Chrome to hard-code this for some domains, especially Google's. This has been extremely useful for turning up imposter SSL certificates, but it doesn't scale at all and thus it doesn't protect your site or my site.)

This means that the (global) security of your domain is hostage to the worst CAs and the CAs that are most subject to government coercion, because any of those CAs can issue certificates that web browsers will accept as valid for your domain. This is real SSL security (as opposed to the theoretical model with perfect CAs) and fundamentally why SSL certificates are a commodity. As the core weakness of SSL it has caused almost all of the SSL certificate security failures; some random CA that should not have any power to say 'I certify that this is website X' for some important X has in fact issued a certificate that says exactly that.

(The CA involved this time around simply makes it that much more obvious than usual, because it was not a general CA.)

This core problem of SSL cannot be fixed by getting better run CAs (or by imposing liability on CAs, never mind the problems with that). Extremely well run CAs are still vulnerable to government coercion and legal orders (orders that may come complete with gag requirements that prevent the CA from speaking out; we have seen that sort of thing in any number of places). For that matter, some CAs are themselves agencies of various governments (and your browser trusts them all and doesn't restrict what they can issue certificates for).

This problem cannot be solved by putting some or many commercial CAs out of business, as Tim Bray proposes. For a start you won't have gotten rid of the CAs that are effectively arms of their government. Beyond that, a root certificate that browsers trust is an extremely useful and valuable asset (perhaps a CA's most important one), one that will be transferred from owner to owner for as long as possible. I'm sure that there are any number of entities who would be happy to operate a CA at a loss merely to have power over such a certificate.

(Also, available evidence says that you can apparently operate a profitable CA that gives away free certificates. This suggests that putting commercial CAs out of business is going to be harder than you might expect.)

As far as I can tell the only way to solve this problem for real is for people to be able to somehow restrict which CAs can issue certificates for their web sites; an extreme version of this is for people to be able to restrict which actual certificates are accepted for their websites. Until this happens we will all remain hostage to all of those CAs that our browsers trust.

(I've written about these issues before, but I don't think I've previously laid out the core problem in black and white like this.)

PS: I hope it's obvious how much of a politically explosive non-starter it would be to try to drop perfectly operable CAs (either commercial or governmental) from browsers. As always, proposing something that cannot be done is not solving the real problem.