A convoluted series of unfortunate events within CA Turktrust led to the existence of a legit-appearing Google domain and the potential for some serious fraud via man-in-the-middle attacks, prompting Google, Firefox, and Microsoft all to block the "*.google.com" domain as of yesterday.
The anomalous domain was not the result of a data breach, according to Turktrust, which mistakenly issued two certificates that ultimately led to the phony Google one. Turktrust traced the incident back to a 2011 audit that required a software migration and moving certificate profiles between a production system and a test system. The Turktrust incident is yet another red flag about the flawed digital certificate authority system, which has suffered a black eye over the past two years with breaches at Diginotar, Comodo, and RSA.
[Following breaches at Diginotar, Comodo, and RSA, digital certificate technology has been deeply tarnished. See Salvaging Digital Certificates.]
"This is probably not a [major security] event, but it points out the problems of this system. It really needs some modification," says Wolfgang Kandek, CTO at Qualys. "The browser vendors are really on the spot to do something [about certificates]."
Turktrust says the accidental issuance of two unauthorized certificates can be traced back to 2011, when certificate profiles on its production system were moved to its test system in preparation for an audit. A few more certificates were added to each system, and the tests were finished by June 30, 2011. "It was the unfortunate event that the production system was patched with the profiles in the test system, which had happened to contain 2 wrong profiles and lacked 3 correct profiles," Turktrust wrote in a blog post. "The wrong profiles were only used on August 8, 2011 to issue those two faulty certificates which were certainly not intended to be sub-CA certificates."
After another round of fixes and tweaks to the certificate profiles that summer, Turktrust passed its audit by KPMG in November 2011. "Therefore the problem had been fixed once and for all although the unfortunate event that the certificates were mistakenly issued remained hidden," the CA says.
One of the two certs was revoked before it was enacted, but the second one was spotted signing the fraudulent "*.google.com" certificate on Dec. 6, 2012. "Before the December 6, 2012, the certificate was installed on an IIS as a web mail server. On December 6, 2012, the cert (and the key) was exported to a new firewall. It was the same day as the issuance of the fraudulent certificate (*.google.com). The firewall was said to be configured as MITM. It appears that the firewall automatically generates MITM certificates once a CA cert was installed (http://www.gilgil.net/communities/19714). The second certificate was immediately revoked as soon as it was brought to TURKTRUST's attention by Google on December 26, 2012," Turktrust says.
The CA says the phony Google cert doesn't appear to have been issued for nefarious purposes. But a Reuters report today cites sources that claim a Turkish government agency may have employed the fake domain in order to monitor its employees.
The errant cert was first discovered on Christmas Eve, according to Google, when Google Chrome detected and blocked it. "We investigated immediately and found the certificate was issued by an intermediate certificate authority (CA) linking back to TURKTRUST, a Turkish certificate authority," blogged Adam Langley, Google Software Engineer. "Intermediate CA certificates carry the full authority of the CA, so anyone who has one can use it to create a certificate for any website they wish to impersonate."
Google then blocked the second errant cert and alerted browser vendors. Microsoft says Turktrust created *.EGO.GOV.TR and e-islam.kktcmerkezbankasi.org): the *.EGO.GOV.TR subsidiary CA was used to issue a fraudulent digital certificate to *.google.com. Microsoft updated its certificate trust list to remove those certs, and Mozilla also revoked those certs and suspended Turktrust's root certificate.
Qualys' Kandek says a secure CA infrastructure depends on the CAs not making mistakes and employing proper security. "This [case] is a good example of the problem we have on our hands right now. Anyone can issue these certs. The protections are best practices and honesty," he says.
Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.