, , , ,

Our certificate authority (“CA”) infrastructure has the flaw that any one CA… can issue a certificate for any web site, anywhere… This was tolerable when the only game in town was VeriSign, but now that’s just untenable.

For years the existing Certificate Authority (“CA”) infrastructure seemed secure to me. Until I decided, just as an experiment, to try to issue my own certificate. While I was not able to seamlessly set myself up for business as the Ellie K Discount Certification Authority, I learned that obtaining a valid certificate, despite being merely an individual, could be done at minimal cost from a variety of “low cost” CA’s. So what can be done about this?

First, some non-solutions: Extended validation certs do nothing useful. Will users be properly trained to look for the extra changes in browser behavior [and act accordingly] when they’re absent via a normal cert? No. Similarly, certificate revocation lists buy you nothing if you can’t actually download them (a notable issue if you’re stuck behind the firewall of somebody who wants to attack you). A straightforward idea is to track the certs you see over time and generate a prominent warning if you see something anomalous. This should be built into every browser.

In addition to your first-hand personal observations, why not leverage other resources on the network to make their own observations? For example, while Google is crawling the web, it can easily save SSL/TLS certificates when it sees them, and browsers could use a real-time API much like Google SafeBrowsing. A research group at CMU has already built something like this, which they call a network notary. In essence, you can have multiple network services, running from different vantage points in the network, all telling you whether the cryptographic credentials you got match what others are seeing.

I liked that idea. It seemed like a sort of peer-to-peer or distributed computing approach to certificate validation.

There are a variety of other proposals out there, notably trying to leverage DNSSEC to enhance or supplant the need for SSL/TLS certificates. Since DNSSEC provides more control over your DNS records, it also provides more control over who can issue SSL/TLS certificates for your web site. If and when DNSSEC becomes universally supported, this would be a bit harder for attacker firewalls to filter without breaking everything….

In fact, we ARE making steady progress toward universal DNSSEC implementation.

Corner cases aside, what if you’re truly in a hostile environment and your browser has genuinely detected a network adversary? Should the browser refuse the connection, or should there be some other option? And if so, what would that be? Should web sites like Gmail and Facebook allow users to have two separate passwords, one for “genuine” login and a separate one for “Yes, I’m in a hostile location, but I need to send and receive email in a limited but still useful fashion?”

I also learned that certificates come in many flavors, for many purposes, some quite narrowly restricted. Certificates can expire, or be revoked by the issuing CA, or be valid for code signing purposes only. Also, certificates are only as good, as credible and secure, as the root Certificate Authority.