Serious Security: Google finds fake but trusted SSL certificates for its domains, made in France

Google announced over the weekend that it recently came across a bunch of fake SSL certificates for some of its own domains.

The bogus certificates were apparently vouched for by the certificate authority of DG Trésor, the French Treasury.

The Treasury’s own authorisation certificate was, in turn, vouched for by IGC/A, the grandly-named Infrastructure de Gestion de la Confiance de l’Administration, or Public Service Infrastructure Trust Management.

Certificates issued by the IGC/A officially identify the Certificate Authorities of the French public service. They also attest to the quality management practices of public keys used by those authorities. They are awarded after an audit and may be revoked for poor practices.

The chain of trust

Generally speaking, your browser uses a chain of digital signatures from certifcate authorities (CAs) to decide if a secure web site is what is claims to be.

We’ve explained this before, during a similar fiasco caused by a Turkish CA, but we shall take another look now, because it’s important.

If you visit the MySophos website, for example, which uses HTTPS, your browser will take you straight there, trusting that the site really is Sophos’s, and displaying a padlock and the words Sophos Ltd. (GB) to denote the company that operates it:

We can click on Sophos Ltd. (GB) to find out more:

If we dig a bit deeper into the certificate, we can extract the information from which your browser derives that identifying name, as well as the websites that this certificate is authorised to vouch for:

   Owner: 
      CN=www.sophos.com 
      O=Sophos Ltd. 
      STREET=The Pentagon 
      L=Abingdon
      ST=Oxfordshire
      C=GB 
       
   Subject Alternative Names: 
      DNSName: www.sophos.com
      DNSName: partnerportal.sophos.com
      DNSName: secure2.sophos.com
      DNSName: forms.sophos.com
      DNSName: www.astaro.com
      DNSName: my.astaro.com
      DNSName: myutm.sophos.com
      DNSName: sophos.com

→ We used the Firefox [Export...] button, shown above, to save the certificate in PEM format as sop.pem. Then we used the Java utility keytool -printcert -file sop.em to dump it in human-readable form. The command openssl x509 -in sop.pem -text would have worked nicely, too.

Of course, anyone can create a public key that says it’s from Sophos, so your browser needs some corroboration:

The chain of trust for this certificate says that it was vouched for (digitally signed) by the GlobalSign Extended Validation CA - G2 key, and that this key, in turn was signed with the GlobalSign Root CA - R2 root key.

And the GlobalSign Root CA - R2 key is explicitly trusted by Firefox itself:

In short, your browser quietly and automatically trusts any HTTPS certificate signed by a CA key (that is signed by a CA key, and so on) that is signed by a CA key that is on your browser’s list of trusted keys.

The final signatory is called the root CA, and the others, unsurprisingly, are called intermediate CAs.

You can add your own trusted CA keys, or simply rely on the built-in list of root CAs that ships with your browser or operating system.

For what it’s worth, the average pre-configured list of trusted root CAs is surprisingly long.

Firefox’s, for example, contains several hundred:

Even though that leaves attackers lots of room for abuse, the need to chain back to a trusted root CA causes problems if you want to do truly comprehensive web filtering (or what you might call surveillance these days) at your company’s network gateway.

To decrypt and scan inside HTTPS traffic, you need to mount what is effectively a Man in The Middle (MiTM) attack: your gateway connects to the requested HTTPS website, fetches the content, decrypts and scans it, and then re-encrypts it before sending it to the user’s browser.

Of course, this means that the web page is no longer signed by the original site’s HTTPS certifcate, but by the gateway’s imposter certificate instead, and this – in most cases – pops up a warning message that the user would riskily need toignore.

Now, your gateway can easily mock up a certificate with the right server name in it, which suppresses any “wrong server name” warnings, but it is much harder to get the mocked-up certificate to be trusted by every user’s browser.

Right and wrong ways to do MiTM

The right way to do it it to create your own CA certificate, e.g. Example.Com Web Scanning Gateway CA, and to add it as a trusted root CA to every operating system and browser on your network.

But that can take a lot of effort, and creates ongoing support friction with visitors and BYOD (Bring Your Own Device) computers.

An easier way, but a highly dubious one, is to persaude a CA – one with a certificate that all your browsers already trust – to sign you an certificate that your gateway scanner can use to mock up digitally signed communications with any domain it likes.

That’s what happened here, it seems.

The goal was indeed surveillance inside a French government department, though apparently not for secret and undisclosed purposes but rather as a useful, perhaps even laudable, effort to improve security.

But you can imagine what can – and in this case did – go wrong.

If any of the temporary, mocked-up certificates should be lost, hacked or stolen, the crooks have an immediate way to masquerade as the web server named in the certificate.

And if the special-purpose intermedate CA certificate itself should be stolen, the crooks can mint themselves a globally-trusted HTTPS identity for any web domain they like.

But companies that sign HTTPS certificates that will be trusted by the world aren’t supposed to do so automatically or in bulk, since they are supposed to be vouching for the identity of the company on whose behalf they are signing.

Clearly, a web filtering gateway doesn’t do that (it iss merely trying to suppress inconvenient SSL warnings), so it shouldn’t be trusted with an intermediate certificate, and that, quite simply, is that.

What to do

If you are setting out to do content filtering, and you are determined to scan your users’ HTTPS traffic, don’t try to cheat by finding a CA that will mint you an intermediate certificate for the purpose.

Do the right thing: mint your own root CA and make your own company’s browsers trust it, so that if there is a certificate leak from your company, it doesn’t affect the rest of the world as well.

If you are a CA, don’t mint intermediate certificates for content scanning, even if the customer promises to use a secure hardware module to store and manage the keys.

Do the right thing: turn down the money and tell the customer to do it correctly.

If you are responsible for SSL certificates at your company, you might also like to take a look at Google’s proposals for Certificate Transparency (explained in simple terms at the end of this article).

It won’t solve the problem of rogue SSL certificates, no matter how keenly Google may want it to, but it does provide a cryptographically-sound and public list of known certificates.

If nothing else, you can interrogate this list from time to time to look for certificates with your name on, but that you didn't create yourself.

That would be a tell-tale sign either of one-off content-filtering "mock certificates" that have escaped, or of someone malevolently trying to spoof, phish or spy on your website or its visitors.

Learn more about SSL