So Google Chrome has a preloaded list of sites they can force SSL on (Strict Transport Security) and certificates they can pin up to (Public Key Pinning). You can request yourself be added to this list over here. But Chrome is open source, so you can look at the code behind this. The relevant file is in transport_security_state.cc and the actual list of directives is in transport_security_state_static.json. Inside that list of directives (and I'm linking to the latest revision, not trunk), there's a property bad_static_spki_hashes.

//   bad_static_spki_hashes: (optional list of strings) the set of forbidden SPKIs hashes

If we look at the only time that's used, it's used by Google.

    {
      "name": "google",
      "static_spki_hashes": [
        "VeriSignClass3",
        "VeriSignClass3_G3",
        "Google1024",
        "Google2048",
        "EquifaxSecureCA"
      ],
      "bad_static_spki_hashes": [
        "Aetna",
        "Intel",
        "TCTrustCenter",
        "Vodafone"
      ]
    },

Those certificates: Aetna, Intel, TCTrustCenter, and Vodafone are defined in transport_security_state_static.certs (again, revision specific not trunk). They were added in this diff with the comment "net: reject other intermediates from Equifax" which references a private code review request and bug. When I open them on Windows 7, they all chain to the GeoTrust root with fingerprint d23209ad23d314232174e40d7f9d62139786633a. GeoTrust (who bought Equifax's CA program) is the company that ran the GeoRoot program, allowing companies to have their own root.

Are these MITM Certificates? No. But before I explain how they're not, a little background:

The practice of issuing companies publicly trusted Certificate Authorities for the purpose of performing MITM on their employees is extremely shady and dangerous and resulted in lots of bad press for Trustwave when they issued one to Micros Systems. They revoked it, and came clean - and I applauded them for it. In the fallout, Mozilla told CAs they couldn't do this and be included in their root program. They had to either not let the root out of their control or technically or contractually constrain them explicitly disallowing MITM purposes.

The responses from the CAs came back. Geotrust said "SubCAs are technically and/or contractually restricted to only issue certificates to domains that they legitimately own or control, and they are specifically not allowed to use their subordinate certificates for the purpose of MITM." And also that they were in the process of "[adding] a statement to [their] CP/CPS committing that [the company] will not issue a subordinate certificate that can be used for MITM or 'traffic management' of domain names or IPs that the certificate holder does not legitimately own or control." And let's take a look at the four certificates blacklisted in Chrome:

Vodafone & Aetna

Vodafone expired in July 2011, Aetna in Aug 2012. Looking at Mozilla's and Windows' Trust Store I don't see an Aetna or a Vodafone.

Intel

This is a valid, trusted Signing CA that is still valid. It can do a lot too: Digital Signature, Certificate Signing, Off-line CRL Signing, CRL Signing. It has a Public CRL that refreshes every three months with no entries. Its other pointers go to unresolvable domains. I can't find an Intel in my trust stores.

TC TrustCenter

This is the strangest one to me - because I do have it in my Trust Store. I have "TC Trust Center Class 2 CA II", "TC Trust Center Universal CA I" and "III", and "TC Trust Center Class 3 CA II" in Mozilla and nothing in Windows (but Windows has some weird polling-the-server stuff IIRC). So if some of TC Trust Center is trusted, why isn't this one? Also, it's still valid. It's CRL is GeoTrust's.

Now these are not MITM certificates. They have been in use on the public internet, and if you search through the SSL Observatory data you will find both the certificates and instances of their signing public certificates. So it's pretty clear these aren't hidden certificates or anything. But the existence of these certificates is still troubling for a brand-new reason: Certificate Pinning.

Certificate Pinning - either by TACK, the upcoming HTTP Header, Chrome's aforementioned system, or other methods - allows you to pin to a leaf certificate or a Certificate Authority's root. If clients see a certificate signed by anything other than the pinned certificate (key, technically) - they will reject the certificate. It allows you to limit the number of signing CAs from dozens or hundreds to a couple of Intermediates. But just how many Intermediate (signing) certificates are off that root you just pinned? You can get a sense of it from the SSL Observatory - but just a sense, because they're not all disclosed.

And that's what Google has done. They wanted to pin GeoTrust - but not these other Intermediates. So they had to go to explicit steps to prevent these four certificates from being able to sign for Google properties, ever ever ever. So if you're evaluating a Certificate Authority, and you want to pin to them, this should factor into your calculations. Mozilla is working on this to provide greater transparency for these 'unknown' Intermediates, which are a subject of great debate.

if 1 * 2 < 3:
    print "hello, world!"