I was recently interviewed by the “Darknet Diaries” podcast about the Diginotar incident, for which I did Mozilla’s security response. Even though this major CA breach happened back in 2011, it still casts a long shadow over the CA industry today, as the scale of the catastrophe has not since been equalled.
The episode is 25 minutes long.
A really good, high-level summary of the history of the SSL/TLS protocols and WebPKI from Feisty Duck.
Version 2.5 of Mozilla’s Root Store Policy has now been published. This document incorporates by reference the Common CCADB Policy 1.0.1.
With this update, we have mostly worked through the backlog of modernization proposals, and I’d call this a policy fit for a transparent, openly-run root program in 2017. That doesn’t mean that there’s not more that could be done, but we’ve come a long way from policy 2.2, which we were using until six months ago, and which hadn’t been substantively updated since 2012.
We also hope that, very soon, more root store operators will join the CCADB, which will reduce everyone’s costs and administrative burdens on all sides, and hopefully allow root programs to be more responsive to changing circumstances and requests for inclusion or change.
If you do certificate pinning, either via HPKP, or in your mobile app, or your IoT device, or your desktop software, or anywhere… do not pin solely to a single certificate, whether it’s a leaf certificate, intermediate or root certificate, and do not pin solely to certificates from a single CA. This is the height of self-imposed Single Point of Failure foolishness, and has the potential to bite you in the ass. If your CA goes away or becomes untrusted and it causes you problems, no-one will be sympathetic.
This Has Been A Public Service Announcement.
Version 2.4 of Mozilla’s CA Policy has now been published. This document incorporates by reference the Common CCADB Policy 1.0 and the Mozilla CCADB Policy 1.0, two new documents which govern our use of the Common CA Database which we hope several root programs will use to ease the administration burden.
This seems pretty super-geeky, but having clear, current, enforceable policies regarding the CAs and root certificates in our root program is important for us to continue to be open and transparent about how we run it, and to enable us to continue to drive the security of the web (which depends on the certificate system) in a positive direction.
The policy had not changed for a long time before this update, so this update addressed issues which were uncontroversial and/or urgent. The next job is to rearrange it into a more logical order and then, after that, for version 2.5, we will be looking at some of the more difficult and longer-term policy challenges we face in this space. Here’s the issue tracker if you want to get some idea of what those are. :-)
With this patch, a shatter’d visage is obscured,
Its’ sneer of cold command in history orphaned.
That one whose results were long once, and secure,
But now resides, antique, imprinted on things best forgotten.
— J.C. Jones’ epitaph for SHA-1
Jacob Hoffman-Andrews (of Let’s Encrypt): “I tried signing up for certspotter alerts for a domain and got a timeout on the signup page.”
Andrew Ayer (of CertSpotter): “Oh, dear. Which domain?”
Jacob Hoffman-Andrews: “hoffman-andrews.com”
Andrew Ayer: “Do you have a lot of certs for that domain?”
Jacob Hoffman-Andrews: “Oh yeah, I totally do!”
Andrew Ayer: “How many?”
Jacob Hoffman-Andrews: “A couple of hundred thousand.”
Andrew Ayer: “Yeah, that would do it…”