19 Feb Trust but verify: when CAs fall short Stefano Ortolani
10 Feb When Certificate Authority Business Models and Vendor Certificate Policies Clash Kurt Baumgartner
04 Nov Regaining Trust in the PKI Kurt Baumgartner
13 Sep Patch Tuesday September 2011 Kurt Baumgartner
02 Sep Was DigiNotar's PKIoverheid CA breached too? Roel
Join our blog
You can contribute to our blog if you have +100 points. Comment on articles and blogposts, and other users will rate your comments. You receive points for positive ratings.
We’ve recently experienced yet another case of a root certificate authority (CA from now on) losing control of its own certificates. And yet again, we have been waiting for either the CA or the browser to do something about it. This whole mess stems, once again, from both a governance and a technical problem. First, only the very same CA that issued a certificate can later revoke it. Second, although web browsers implement several techniques to check the certificate’s revocation status, errors in the procedure are rarely considered hard failures.
A very important “internet trust” discussion is underway that has been hidden behind closed doors for years and in part, still is. While the Comodo , Diginotar, and Verisign Certificate Authority breaches forced discussion and action into the open, this time, this “dissolution of trust” discussion trigger seems to have been volunteered by Trustwave's policy clarification, and followup discussions on Mozilla's bugzilla tracking and mozilla.dev.security.policy .
The issue at hand is the willful issuance of subordinate CAs from trusted roots for 'managing encrypted traffic', used for MitM eavesdropping, or wiretapping, of SSL/TLS encrypted communications. In other words, individuals attempting to communicate over twitter, gmail, facebook, their banking website, and other sensitive sites with their browser may have their secure communications unknowingly sniffed - even their browser or applications are fooled. An active marketplace of hardware devices has been developed and built up around tapping these communications. In certain lawful situations, this may be argued as legitimate, as with certain known DLP solutions within corporations. But even then, there are other ways for corporate organizations to implement DLP. Why even have CA's if their trust is so easily co-opted? And the arbitrary issuance of these certificates without proper oversight or auditing in light of browser (and other software implemented in many servers and on desktops, like NSS ) vendor policies is at the heart of the matter. Should browser, OS and server software vendors continue to extend trust to these Certificate Authorities when the CA’s activities conflict with the software vendors’ CA policies?
The SSL PKI has been in use and implemented for 15 years now to secure online communications. From its initial proprosals and immediate growth, the need for secured online communications has been met with challenges. The infrastructure and protocol itself is showing signs of wear, with multiple attacks and corrections to the scheme itself. And in its 15th year, an alternative to the Cerificate Authority infrastructure is finally being given some competition with the release and debate around Convergence, an open source alternative to the current system of Certificate Authorities. Feel free to right click and download for the full sized version; the graphic below provides a list of some of the major events for SSL/TLS PKI in the past 15 years.
This month's Microsoft patch release is pushed out with lower urgency recommendations overall. While the Sharepoint and server side vulnerabilities are interesting, IT and individuals should attend to the Excel vulnerabilities with urgency. Microsoft is also putting to bed any issues related to Diginotar certificate trust by adding cross signed Diginotar root certificates to the Microsoft Untrusted Certificate Store.
Only five security bulletins are being distributed along with the Diginotar Certificate additions and updates. None are labeled with "Deployment Priority 1". However, in light of the ongoing spearphishing and targeted attacks, the most relevant and important of these arguably is the Excel related bulletin, MS11-072. While it is being listed as "Important", not every enterprise has rolled out the latest version of Excel to all of their systems. A set of "use-after-free" and other heap corruption vulnerabilities that are very difficult to discover with automated auditing frameworks plague the application. These vulnerabilities can be exploited to execute spyware, backdoors, and downloaders of the attackers' choosing on victim systems. Excel related email attachments and links have commonly been used in targeted attacks on organizations and this one should be addressed.
Excel can be a major problem. The RSA breach "2011 Recruitment Plan.xls" file made it very clear how social engineering schemes are used to effectively trick employees - it is important to note that the message was pulled out of the RSA employee's spam folder and opened. This Excel attachment maintained embedded malicious Flash content and exploited the vulnerability right in front of the employee after being opened, effectively delivering its cyber-espionage payload. Now, attackers don't need embedded Flash content to take advantage of employee dependency on Excel.
In an almost unprecedented event the Dutch minister of internal affairs gave a press conference at 1:15 AM Friday to Saturday night. He announced the Dutch government was revoking trust in Diginotar.
Diginotar basically consisted of two seperates branches. One branch was a certificate authority which dealt with regular businesses. The other branch was focused on government and called "PKIoverheid". The audit conducted on Diginotar's systems showed the integrity of the PKIoverheid authority couldn't be guaranteed. It should be presumed the integrity is broken.
At the beginning of last week the Dutch government had vouched for the integrity of the PKIoverheid CA. This caused the browser makers to only blacklist the non-goverment CA from Diginotar. Next time around browser makers won't be quite as trusting.
The attack on Diginotar doesn't rival Stuxnet in terms of sophistication or coordination. However, the consequences of the attack on Diginotar will far outweigh those of Stuxnet. The attack on Diginotar will put cyberwar on or near the top of the political agenda of Western governments.
Here's a break down of most of the important takeaways from this incident:
Earlier this week DigiNotar said another audit would be performed and the results of this audit would be made public.
One of the big questions is whether the government CA branch - called DigiNotar PKIoverheid - has also been compromised.
In seeming preparation of these results, the Dutch government has sent out an email to users who've been issued a certificate via the DigiNotar PKIoverheid CA. All these companies/services are tied to the government or public services. Pending the results of this audit the Dutch government is asking PKIoverheid certificate owners to do the following:
- List the PKIoverheid certificates in the organisation.
- List the processes for which these certificates are being used.
- List the consequences in case the PKIoverheid certificates can no longer be trusted.
I think it would be wise at this point for the affected browser makers to start preparing an update which will also blacklist DigiNotar's PKIoverheid CA. Pending the outcome of the audit, of course.
A lot of Dutch government sites and services are going to be affected by the revocation. Clean up is going to be painful.
The Dutch government has used DigiNotar as an intermediary CA in quite a lot of cases. The Dutch government actually has a root CA of their own. It could be leveraged to quickly produce new certificates for affected services.
I hope it's truly clear now that the Dutch government needs to distance itself from DigiNotar.
In the Netherlands news just broke involving more details with regards to the DigiNotar compromise. According to this the following were included in the targeted domains: Yahoo.com, mozilla.org, torproject.org, wordpress.org and Iranian blogging platform Baladin.
So far, I haven't been able to verify these myself. It would be great if any of the browser makers or DigiNotar could confirm these were amongst the targeted domains.
Assuming these domains were indeed targeted the most plausible explanation is that a specific government is behind this attack.
What's worrisome in this saga is DigiNotar's claim a "few dozen" rogue certificates were generated. This is a particularly suspicious claim because at the same time Google has blocked over 200 rogue certificates. Something doesn't quite add up.
It gets worse though. According to DigiNotar they're not able to track which rogue certificates were generated. So more of these rogue certificates may be out there. How is this possible? Either DigiNotar performs no logging of the certificates they create or their logs got cleaned out during the attack.
Either answer is bad and neither of them is worthy of the trust we necessarily have to put into certificate authorities.
DigiNotar's response to this whole debacle has only made me more worried about how deep this attack may have run. To me, it seems that DigiNotar has not realized certificate authorities need to sell trust above anything else.
The browser makers have responded by exiling DigiNotar from the PKI chain. Now we're waiting for the Dutch government to do the same.