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
(Audio player not working? Download MP3, or listen on Soundcloud.)
8 comments on “Serious Security: Google finds fake but trusted SSL certificates for its domains, made in France”
Speaking of SSL, when I try to reach this site using HTTPS, I receive an SSL error and this message in Chrome (similar on in IE):
“You attempted to reach nakedsecurity.sophos.com, but instead you actually reached a server identifying itself as *.wordpress.com. This may be caused by a misconfiguration on the server or by something more serious. An attacker on your network could be trying to get you to visit a fake (and potentially harmful) version of nakedsecurity.sophos.com.
You should not proceed, especially if you have never seen this warning before for this site.”
I am sorry to have to say that your best solution is to read NakSec via HTTP 🙁
The server is hosted by WordPress.com VIP, so it doesn’t identify itself as nakedsecurity.sophos.com (which is a CNAME in DNS) in its SSL certificate.
Seems like the same situation like when DigiNotar got comprimised by Iranian hackers, making all the certificates of the Dutch Government possibly comprimised. Scary stuff.
Trustwave did something similar back in 2012, IIRC. They kind of thought it would be OK because the intermediate private key was only ever in a hardware security module, and so were the generated-on-the-fly MiTM mock certificates. After a bit of a panelling from the Mozilla guys, who said, “That’s not cricket,” (or whatever the American equivalent of that saying might be), Trustwave agreed and said they wouldn’t do that again, ever, honest.
Looks like ANSSI and IGC/A didn’t follow that story…
Digitnotar was worse, because the hackers just wandered in and minted a raft of new certs for themselves 🙁
Could you explain what this might mean to a customer with a web application gateway (proxy), where the SSL traffic is split to allow DLP interception?
If the endpoint only sees the company’s certificate, does the gateway check the certificate? Where is the perimeter for the certificate?
We’re using Forefront TMG at work which performs HTTPS inspection using the ‘install my certificate on every device’ method which is a PITA! Just wondering if the Sophos gateway appliance does the same thing?
Yes, you need to authorise your “mock certificates” if you wish to avoid certificate warnings when doing HTTPS inspection. You can consider that a feature, not a flaw.
Thanks, I’ve deleted IGC/A from my Firefox Authorities