My early-week post on the MITM certificate mess seems
to have struck a nerve with readers. (Or perhaps I just picked the right time to complain!) Since folks seem interested in this subject, I wanted to follow up with a few quick updates:
- The EFF has released a new version of HTTPS Everywhere, which includes a nifty ‘Decentralized SSL Observatory’ feature. This scans for unusual certificates (e.g., MITM certs, certs with weak keys) and reports them back to EFF for logging. A very nice step towards a better ‘net.
- StalkR reminds me that Chrome 18 includes support for Public-key Pinning. This is an HTTP extension that allows a site operator to ‘pin’ their site to one (or more) pre-specified public keys for a given period of time. A pinned browser will reject any alternative keys that show up — even if they’re embedded in a valid certificate.
- A couple of readers point out that popular sites (e.g., Google and Facebook) change their certificates quite frequently — possibly due to the use of load balancers — which poses a problem for “carry a list of legitimate certs with you” solutions. I recognize this. The best I can say is that we’re all better off if bogus certs are easy to detect. Hopefully site operators will find a compromise that makes this easy for us.
Appearances to the contrary, this blog is not going to become a forum for complaining about CAs. I’ll be back in a few days with more wonky crypto posts, including some ideas for dealing with bad randomness, some thoughts on patented modes of operation, and an update on the progress that researchers are making with Fully-Homomorphic Encryption.
A Few Thoughts on Cryptographic Engineering 
Moxie's convergence is “fix problem now”
and the correct long term fix (or the correct direction) is Ben Laurie/Adam Langley's approach Certificate Transparency. The key idea is that every cert issued should be known to the world http://www.links.org/?p=1226
Please notice that your third point (“it's hard to carry a list of valid certificates”) is exactly why Chrome supports public-key pinning, as opposed to certificate pinning. The idea is that, in a large deploy, you might have a small set of private/public keys, but you can have many different certificates, from different CAs, with short expiration. If you pin the public key, you can change as many certificates as you want, and there's no real rason to change the public key unless you think that the private key is compromised.
Public-key pinning is also what allowed Google Chrome users to be notified when Iran tried to MITM their population using the *.google.com certificate obtained through the Diginotar hack. while all other browsers were unable to warn the users.
If I understand right, the problem with these large sites is that for multiple servers reachable by the same IP address (and serving the same site), you normally wouldn't have the same private key in each of them, would you? How would key pinning help here?
Ah, got it … you don't pin a server's public key, but you are listing some key fingerprints, one of which must be present in the certificate chain of future connections. Thus Google is in effect pinning the “Google CA” for future connections to Google.