Comodogate Fallout. Certificate Pinning.

Updated;

Continuing on the fall-out from Comodogate, various browsers are implementing new Certificate mechanisms that will help restore some trust to the system.

First up, Adam Langley who works on Google Chrome and runs the blog http://www.imperialviolet.org/ is talking publicly about a new feature for Chrome 13 called certificate pinning.

First the good.

Certificate Pinning will allow a browser to define what certificates will be valid for a specific site and give a time-frame with which it will be valid. You can pin right to the leaf, but realistically you're going to want to pin to the CA. Google's now apparently going to pin to four CA's "Verisign, Google Internet Authority, Equifax and GeoTrust" if your browser sees a valid Google.com certificate from say, Comodo's CA... its going to hard fail.

Brilliant, awesome and significantly reduces the threat of a rogue CA and of CA compromise. 

The bad news.

They deliberately crippled it. From Adam Langley's blog:

"There are a number of cases where HTTPS connections are intercepted by using local, ephemeral certificates. These certificates are signed by a root certificate that has to be manually installed on the client. Corporate MITM proxies may do this, several anti-virus/parental control products do this and debugging tools like Fiddler can also do this. Since we cannot break in these situations, user installed root CAs are given the authority to override pins. We don't believe that there will be any incompatibility issues."

With this, it means that any virus that installs a CA can override the pin. I've talked about this as a threat vector for electronic voting... and its a significant concern that the browser makes no effort to explain that a self-signed CA is being relied upon and that the connection may not be secure. No, rather, the browser actually says you are talking on a secured connection. I think many users who sit down at their pre-configured corporate terminal would be surprised to learn that Google is collaborating with your employer to make sure they can read your traffic -- traffic which you believe based on the browser UI is secure.

Which brings up a huge question -- which corporations issue on-the-fly certificates for public websites? What is the current legality of such actions in Canada remembering that under our legal system employers do not have the inherent right to breach the privacy of their employees even when using company computers or networks.

In my opinion chrome has failed here pretty epically, by with one hand giving a wicked security feature, and with the other DELIBERATELY ALLOWING MITM ATTACKS.

Wtf. Google, Goofing again.

--

As an aside I have continued my research into NSS and have some interesting findings to share. First, its entirely possible for a non-privileged user account to add a certificate to the NSS store -- _any_, and I mean _any_ compromised application running as your local user has the ability to write to the NSS key store. (Firefox doesn't appear to implement any privilege escalation API's to add a CA certificate for example)

One good thing though, the list of EV CA certificates is more restricted -- and to include a custom EV cert requires running a special debug build of firefox. I'm not sure I agree with this policy -- being able to add an EV certificate authority to a browser, and then to pin a corporations intranet application certificates to it would be hugely useful. I've even discussed it in the context of soft-launching a CIRA CA authority before applying for certificate inclusion. Regardless, it should require administrative level access to modify the trusted CA list. 

As such, I have been tracking a new vector for electronic voting fraud, in that a virus that exploits a zero-day flaw in the browser (and there are new flaws found regularly) would be able to inject a CA certificate without causing any noticeable damage. Updated: Original: By injecting it into NSS directly as a 'built-in' object, early indications suggest that it may even be possible to hide the certificate from the UI dialogs, making its detection nearly impossible, however more research is needed on this front and I do not yet have a proof of concept. Updated: After further discussions it turns out that currently Firefox 4 does NOT use the Bogus Certificates from the NSS store yet, and thus while the certificates appear to be hidden in the Certificate Manager's "Servers Tab", it is only because they are not being used directly from NSS in this way. Currently Firefox uses a code-level module called PSM to handle the bogus certificates, by serial numbers and certificate names, and its contents are not modifiable at runtime. However, for applications that do rely on newer versions of the NSS lib (like currently shipped versions of Thunderbird as packaged on Ubuntu), you will see the certificates installed under the Certificate Manager's 'Servers' tab, and they are not hidden from view. Thus, while certificate injection by a virus running with user-level permission is possible, it does not appear to be possible to hide presence of a CA from the Firefox UI dialogs and such a hack should be noticeable to those with a keen eye.

The hack would go something like this: Find a zero-day flaw in jpeg, png,  gif, etc, and distribute a truly viral image -- something like the Mayor of Vancouver doing something silly, or even just a graphic on a voting lobby website [think hacking votenet.ca or something similar before an election] ... Once the CA is installed at the browser level, a network attack near the user (like at the ISP aggregation nodes) is easy. Theres about 6000 customers per node on cable-internet systems in Vancouver. and their neighbourhood aggregation nodes have low physical security [ at least when compared to that of a datacenter hosting the voting site/application]... its the low hanging fruit. The likely hack is that a cable tech hacks the router, and deploys a hacked image -- election stolen and its not only impossible to prove it was stolen, but its impossible to detect the extent of the damage.

And this is all assuming you're not a rogue government and you cant just get the pinned CA to issue any cert you want under NSL. Electronic voting is quite simply insane -- and according to Google SSL MITM is so prevalent that they wont even break Chrome's support for it! What happens when a rouge sysadmin at some big Vancouver company does a MITM attack on a few thousand in-house computers?  Or say, on any large network where updates are centrally deployed?

No, we must reject e-voting, and we must reject Chrome's policy of allowing pin overriding.

In summary:

Pinning = great. Local overrides = bad. E-Voting = Insane.