More on the user experience with digital certificates

In part six of the "Digital signatures" series I talked about the poor user experience associated with managing certificates. I'd like to say more about that here.

In a good paper by Dhamija, Tygar, and Hearst at the CHI 2006 conference, titled "Why Phishing Works", 22 students and university staff members were presented with a set of web sites. Specifically in relation to the user experience with certificates, the researchers have this to say:

Knowledge and Use of Certificates. When presented with a browser warning for a self signed certificate, 15 participants immediately selected "OK" without reading the warning dialogue. The default option selected in this case is to "Accept this certificate temporarily for this session". When asked if they knew what they just accepted or declined, only one participant was able to correctly articulate the choice he had just made. 18 responded that they did not know and 3 gave incorrect answers (i.e., "I accepted the use of cookies"; "It asked me if I wanted to save my password on forms"; "It was a message from the website about spyware").

Only one participant gave a correct definition of the purpose of certificates and could interpret the website certificate that we asked the participants to inspect (he was a system administrator). 19 participants stated that they have never checked a certificate before. Only 3 participants stated that they ever checked a certificate (or saw something similar to the certificate that was shown).

What Dr Dhamija and his colleagues found dovetails with what I said in the user-experience segment of this series:

If those or any other problems show up with the certificate, you, the user, will see a pop-up message telling you about the problem and asking what you want to do about it. Only: how on Earth do you know what to say? Maybe after reading this you'll have a clue, but, really, it's beyond the knowledge of most users to cope with certificate problems, and generally the problems aren't something a user can resolve anyway. The only real choices are to accept the certificate for now, or not... and since not accepting it means that you can't use the web site you're trying to use, it's clear which choice most users will make.

And most of the time that'll be the right choice, because most of the time it's just that the system administrator forgot to install the renewed certificate, and all will be fine by tomorrow. On the other hand, it could be that someone has hacked the web site and is trying to steal account numbers and passwords. Would you know enough to tell the difference?

The situation in the study is of the use of self-signed certificates, so let's look again at what that means. Have a review of the segment on certificates: each certificate you're presented with contains that entity's public key, and each certificate is signed by one or more certifiers that verify the connection between the key and the domain (the address of the web site or the sender of the email). Certificates are usually signed by known certificate authorities (CAs), but that doesn't have to be the case. There are reasons that legitimate users might not want to obtain their certificates from a CA. For one, CAs charge money for the service. And CAs that don't charge money have (for good reasons; they have to be sure of the identity of the entity they're assuring) an involved process for obtaining an assured certificate (here's a pointer to the process for CAcert, for example). An alternative to paying money or working through an inconvenient procedure is simply to create the certificate yourself — to create a self-signed certificate.

The trouble with self-signed certificates is that no trusted authority has vouched for anything. I can't get a certificate from Verisign (nor from CAcert) that says I'm citibank.com, but I can create my own self-signed certificate that says so. And that would make it easy for me to send email or to put up a web site that masquerades, if we had no other protection.

We do have further protection: web browsers and email programs check the certificate's signers and make sure that some trusted authority has signed the certificate (and that the address in the certificate matches the web site or email sender). If it doesn't find a trusted signer — and it won't if the certificate is self-signed — it will ask the user what to do. Unfortunately, as Dr Dhamija's group found, vanishingly few users understand what those pop-ups mean or what they should do about them.

The correct answer to the study's question of what the participants had just accepted or declined is that they accepted an encrypted connection to a web server without any assurance that the server belongs to the company they think it does. Now, that isn't, in itself, a problem, but it becomes a problem when you think that having an encrypted connection means that it's safe to use the web site to log in, enter personal information, and so on. And we're taught to look for the little "padlock" symbol and to think we're safe if it's there (but read the CHI paper for more on that too), so by blindly accepting self-signed certificates we've made the padlock meaningless.

We might say, "OK, then the solution is to change the default answer to 'dont accept', and teach people not to say 'yes' to these popups." The trouble with that is twofold:

• There are a number of situations that can cause such popups, and the risks and best responses differ among them. This makes it hard to advise users in general.
• It's an evil truth that legitimate domains are using self-signed certificates (as well as allowing their certificates to expire, using non-transparent redirection, and other things that they shouldn't be doing, but that cause notifications to the user). Until that stops, it's too disruptive to give such blanket advice.

In fact, because of some domains' desires to allow themselves the flexibility of things like non-transparent redirection, some sites actually defeat the padlock symbol themselves, hiding the fact that they're using an encrypted session (PayPal does this, for example). Some of those sites (though not PayPal) try to compensate by putting a padlock symbol in the web page content — an untrustworthy place that nevertheless adds greatly to user confusion (see the CHI paper for more on that too).

What all this points out is that it's hopeless to try to present security-related questions like these to end users, because there's no hope that they'll understand what the questions mean, much less know how to respond. And what that means is that until all this works flawlessly, such that the error case for a legitimate address is the truly unusual thing that shows up once a year, what we have is a web system with gaping, exploitable holes and an email system that's essentially unworkable as a secure system.