This is a continuation of the Digital Signatures overview series.
3.4 The User Experience
Everyone who has used the World Wide Web for much has encountered "secure web sites" — web sites with the protocol prefix "https", which display some sort of padlock symbol when they're visited. These web sites use X.509 certificates, and are proof that it all mostly works. Most of the time, you visit such a web site, your browser retrieves the site's certificate, validates it using the CA database that we looked at through the "options" window, above, then negotiates an encrypted session using the information from the certificate. The user sees none of this, and only notices (perhaps) that the padlock symbol appears in its appointed spot in the browser.
Most of the time. Because most of the time, the certificate has not expired and is signed by a root CA that's known to the browser, and the web site address in the certificate matches the address of the web server you've visited. But there are web sites out there that are not managed so well, and even with the best of management, errors occur. Maybe the certificate expired yesterday and they neglected to install the new one in time. Maybe they have a alias misconfigured, and the certificate is for banana.example.com but the server identifies itself as banana-02.example.com. Or maybe the site avoided paying a CA, and used a self-signed certificate, so your browser can't attribute this certificate to a CA in its trusted list.
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?
With email using S/MIME, the same issues come up. Certificates are used in essentially the same way for checking signatures as they are for validating web sites. Except personal email addresses are maintained more casually than are most web sites. Did the sender forget that his certificate expired last week? Or last month? Did he change his email address and forget to get a new certificate? Does he have his email program correctly configured to use the right certificate for the email address he's sending as? Did he get his certificate from a CA that your email program has heard of?
It gets more complicated when you add encrypted email also, because now both sides have to be set up right. As it turns out, there's little use of secure email because of the difficulties of dealing with PGP keys or X.509 certificates for S/MIME.
Next time: DKIM — Signing at the Domain
No comments:
Post a Comment