- Identity or Encryption? / Who Does the Signing?
- Certificate Revocation / Who Do You Trust?
- Disagreements / DNSSEC for Key Distribution
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Certificate Revocation
In an ideal world, CAs would only sign valid certificates, but designing a security system that only works in an ideal world is generally considered a bad idea. After all, in an ideal world, you wouldn't need security.
In practice, sometimes certificates are signed in error. Sometimes they're signed intentionally, but then compromised, and they need to be revoked. If you get a signed certificate that expires in three years, and then someone compromises your server and copies the certificate, you don't want that person to be able to keep using your certificate.
The first attempt at supporting certificate revocation was the idea of revocation lists. Each CA publishes a certificate revocation list (CRL); browsers are supposed to collect a copy of the CRL and make sure that certificates they trust are not on it.
This design sounds fine, but there's a very simple problem. Nothing stops an attacker who's already spoofing traffic from redirecting the browser's request for the CRL. If the CRL isn't found, browsers will assume that the certificate is valid.
A better design is the online certificate status protocol (OCSP). This approach works the other way around, assuming that all certificates are invalid until they've received a confirmation. Before trusting a certificate, a client supporting OCSP contacts the signing CA and says, "Is this certificate still valid?" If the CA doesn't respond, the certificate is not trusted. Of course, if a CA's root certificate is compromised, someone can then sign the certificate that's used to check the OCSP response. Fortunately, this happens quite rarely, and vendors push patches quite soon afterward. OCSP isn't very well supported yet, but it's a good start.
Who Do You Trust?
If you look at the list of CAs that your browser trusts, you might be quite shocked. I've never even heard of most of the ones that ship by default, yet apparently I trust all of these companies enough to use their opinion to verify the identity of absolutely anyone online.
I don't know whether I should trust them. I've never audited their security. Some of them, like VeriSign, I know have handed out invalid certificates in the past. The major browsers have different criteria for acceptance, but they basically boil down to "spend a big chunk of money." The term big is relative, though. Microsoft used to require a third-party security audit that cost $65,000. That's a lot of money for me to spend, but if I were a scammer then I'd expect to make $65K easily while pretending to be various banks, or pretending to be online shops and taking people's credit card details without delivering anything.
Or I could just set up a bogus CA, spend the money on the audit, and charge $5,000 for a certificate, without any kind of validation that you own the domain. I'm sure that I'd find a lot of my customers were criminals, and I could happily revoke their certificates a few days after they'd been caught-while I continued to look legitimate.