Security snake oil

February 20th, 2006

[Originally posted 11th November, 2003, back when I was working at an Internet café, and when Firefox was called Firebird.]

A woman came in last Friday to check her e-mail, but soon stopped to ask for help because “this box keeps coming up all the time”. “This box” was an Internet Explorer security alert warning that the Webmail site’s “security certificate was issued by a company you have not chosen to trust”. And because it was an alert, of course, the woman didn’t read it at all.

(Yes, I’d like the cafe computers to be running Firebird instead of Internet Explorer. But Firebird doesn’t work on our computers, and even if it did, the equivalent alert would be only slightly better.)

Given a choice of “Yes”, “No”, and “View Certificate”, “Yes” seemed the only useful choice — but the same alert reappeared for every page on the site, and for every graphic on every page, and batting away a dozen alerts per page wasn’t tolerable. Okay, so how about “View Certificate”? That didn’t reveal anything useful either — even choosing to “Install Certificate” didn’t make the alerts go away, so eventually I had to admit defeat.

To me, SSL security certificates have always seemed particularly stupid usability-wise. As I understand it, the system works like this:

  1. Alice trusts Fred.
  2. Fred trusts Bob.
  3. Bob gets a certificate of trustworthiness from Fred.
  4. When Alice visits Bob’s page, Bob shows Alice his certificate to demonstrate his trustworthiness.

The problems with this system are as follows:

  1. Alice doesn’t really trust Fred.
  2. Fred doesn’t really trust Bob.
  3. Getting a certificate is too hard, so Bob doesn’t bother.
  4. Even if Bob does get a certificate, Alice ignores it.

I’ll explain each of these in more detail.

  1. Alice doesn’t really trust Fred. Fred is a “certificate authority” (or “CA”), an organization set up to provide certificates to those who deserve them. In theory, Alice gets to choose which certificate authorities she does and does not trust. In practice, the probability Alice knows enough to make this decision is on the order of 1 in 1000.

    To get around this, a select group of certificate authorities are anointed by Web browser vendors, or e-mail program vendors, appearing in a list that the software trusts by default. But this still doesn’t solve the problem, because Alice doesn’t know why a certificate authority is on that list — indeed, the software vendor might not even know themselves.

    The most egregious example is that most browsers and mailers automatically trust certificates from Verisign Inc. — even though there are all sorts of reasons why Alice might not trust Verisign in general, and good reasons why she might not trust certificates from Verisign in particular.

  2. Fred doesn’t really trust Bob. Bob’s certificate is supposed to demonstrate that he is who he says he is, with Fred vouching for that fact. But often, all that’s happened is that Bob has paid Fred some money. Some certificate authorities check that Bob is really Bob, but many don’t.

  3. Getting a certificate is too hard, so Bob doesn’t bother. This is something I was only dimly aware of until yesterday, when I remembered a strange detail of the certificate for this woman’s Webmail site: it was signed by “Snake Oil CA“. This seemed, to put it mildly, a strange name for a certificate authority. So yesterday I did a little Googling, and found a fascinating extract from a usability report on public-key infrastructure in general (emphasis added):

    There is considerable evidence from mailing lists, Usenet newsgroups and web forums, and directly from the users themselves, that acquiring a certificate is the single biggest hurdle faced by users. For example various user comments indicate that it takes a skilled technical user between 30 minutes and 4 hours work to obtain a certificate from a public CA that performs little to no verification, depending on the CA and the procedure being followed. Obtaining one from non-public CAs that carry out various levels of verification before issuing the certificate can take as long as a month. A representative non-technical user who tried to obtain an (unverified) certificate from a public CA took well over an hour eventually the user gave up.

    The problems that this creates are demonstrated by what happens when technically skilled users are required to work with certificates … Certificates used with mailers that support the STARTTLS option consist of ones that are “self-signed, signed-by the default Snake Oil CA, signed by an unknown test CA, expired, or have the wrong DN“. The producer of one widely-used Windows MUA reports that in their experience 90% of the STARTTLS-enabled servers that they encounter use self-signed certificates. This reduces the overall security of the system to that of unauthenticated Diffie-Hellman key exchange, circa 1976. In all of these cases, the entire purpose of certificates has been completely short-circuited by users because its just too difficult to do the job properly.”

    The result of this is unfortunate, to say the least: only 1 percent of Web servers use secure connections. When you set up a Web site using Apache, or IIS, or whatever, everything it sends out is insecure by default. If it was secure, Web browsers would be putting annoying alerts in your readers’ faces all the time, and if you didn’t want that you’d have to get a certificate signed by one of the CAs on that mysterious default list, and getting such a certificate is too hard.

    To some, that may not sound too serious. Who cares if someone’s snooping on the Web pages I visit? It’s hard to answer that question without sounding paranoid. But with my usability hat on, I’m bothered about the annoying alerts. Remember when you first started using your current Web browser, the first time you typed anything in a form (doing a Web search, for example), up popped an annoying alert saying something like “the information you are sending is insecure and could be intercepted in transit”? If all Web sites used secure connections, that alert would be eliminated.

  4. Even if Bob does get a certificate, Alice ignores it. When a Web site’s certificate is signed by a certificate authority the Web browser doesn’t recognize, what’s the poor browser to do? It can continue over a potentially compromised connection, or it can stop and prevent the user from seeing what she wants to see.

    What current browsers do is put up a nasty alert offering these two choices, in some pretense of saving the user from an insecure situation. It’s a pretense, because most humans don’t read alerts, and even if they read this one, they overwhelmingly choose to continue over an insecure connection anyway.

So that’s why I have such a poor opinion of security certificates: they’re a demonstrably unusable solution to the wrong problem. Now, someone please tell me why I’m wrong.