Sophos Cloud Optix
Some days I feel like a broken record that keeps repeating the same story. Today’s repeat meme? Certificate Authority issues certificates leading to Google users being spied upon.
Google first detected the problem, using Chrome’s certificate pinning, on December 24th, according to a blog post titled “Enhancing digital certificate security.”
That title is a bit misleading, as this notification was not at all about proactively enhancing the safety of digital certificates, rather more of a mopping up from a large accident.
An unknown Google Chrome user was alerted to a validly signed Google certificate that did not in fact belong to Google.
Someone was attempting to perform a man-in-the-middle attack against this user’s secure communications intended for Google.
We don’t know where this occurred, but it doesn’t technically matter very much. This means a Certificate Authority either issued certificates to someone who shouldn’t have them or was compromised.
What I think it means is what I’ve said before: we can’t trust the current Certificate Authority based SSL/TLS system. It is broken and I do not believe it can be easily fixed.
Google looked at the signing chain on the certificate and determined the bogus *.google.com certificate was issued by an intermediate Certificate Authority that gained its authority from Turkish CA TURKTRUST.
This intermediate certificate looked odd and in fact it was very odd. It wasn’t supposed to exist.
After reporting the incident, TURKTRUST discovered it had accidentally issued two intermediate certificates instead of normal site certificates in August 2011, including the one used to sign the fake Google certificate.
What exactly is an intermediate certificate? Without explaining the entire SSL/TLS certificate process, an intermediate certificate is essentially a master key that can create certificates for any domain name.
These certificates could be used to impersonate any website to any browser without the end user being alerted that anything is wrong. Still get a padlock, still shows everything as valid.
When you trust the padlock in your browser to be an indicator of security, you aren’t just trusting the ~150 CAs trusted by Mozilla, Microsoft and Google.
According to the EFF’s SSL Observatory, users of Firefox on MS Windows sampled in 2010 encountered 1,482 different signing authorities (including intermediate certificates), all of which the average user would blindly trust.
You are trusting that not a single one of them has decided to collude with someone who wants to snoop on your traffic, none of them has a virus or has been hacked and none of them is being compelled by a government to help out with a wiretap.
Ahem.
So once again we go through the process of revoking these certificates and deciding how much future trust to put in TURKTRUST.
Google has been blocking certificates signed by the mis-issued intermediate certificates for Chrome users since December 26th. Later this month they will rescind the ability for certificates signed by TURKTRUST to appear to have extended validation (the green highlight in the address bar).
Microsoft issued an advisory today revoking all certificates signed by the intermediate certificates for all supported versions of Windows. Windows 8/Server 2012/RT users will get this update automatically; those using older versions of Windows will need to use Windows Update.
Mozilla issued a statement announcing they will be revoking the two intermediate certificates next Tuesday, January 8th (Pacific Standard Time presumably) with the next release of Firefox.
Mozilla will also temporarily revoke TURKTRUST’s root certificate entirely, pending further review.
Opera has yet to make a comment, although users can manually remove TURKTRUST from the list of trusted root authorities if they choose.
Apple, as always, has not commented on when or if they will take action to protect Safari and iOS users against any fallout from these certificates.
It is really time we move on from this 20-year-old, poorly implemented system. Whether it is the Public Key Pinning Extension for HTTP, Convergence, Trusted Assertions for Certificate Keys (TACK) or DNSSEC-TLS, we’ve got to pick something and start implementing it.
It doesn’t need to be perfect to beat what we have. We have had fun arguing the merits and weaknesses of these proposals for ten years at conferences. It’s high time we get to work.
Update: It appears the Google certificate was issued automatically and by accident by the Ankara transit authority and was not used in any attacks. This is no less of a security fail. It took an accident to find an 18 month old accident that could have ended much worse. If we don’t have the ability to know how many more “accidents” have occurred, the system is still broken.
Broken padlock image courtesy of Shutterstock.
For Windows Vista and Windows 7 users who have installed the Certificate Trust List auto updater as described in the following knowledge base article, they should receive the certificate update automatically:
http://support.microsoft.com/kb/2677070
Windows 8 and Windows RT already have the automatic updater installed by default.
To verify this automatic certificate update was installed, you can use the Event Viewer (available from the Control Panel->Administrative Tools) as follows:
——————————————————————–
Check the Application log in the Event Viewer for an entry with the following values:
Source: CAPI2
Level: Information
Event ID: 4112
Description: Successful auto update of disallowed certificate list with effective date: Thursday, January 3, 2013 (or later).
——————————————————————–
All other versions of Windows e.g. Windows XP, Windows Server 2003 etc. or those who chose not to install the automatic updater should use Windows Update.
Additional information is provided in the security advisory linked to by Chester above. I hope this helps. Thank you.
You missed the thing we have picked and are implementing – namely Certificate Transparency (http://www.links.org/files/CertificateTransparencyVersion2.1a.pdf).