On April 11, 2011, the Dell SecureWorks Counter Threat UnitTM (CTU) posted a blog entry titled 'Certificate Authorities for SSL/TLS: Crypto's weak link', which discussed some of the strains of the current Certificate Authority (CA) system for validating web site identity. The backdrop to this blog entry was the breach of Comodo [2] and their resulting issuance of untrustworthy, but valid, certificates.
In recent weeks, another CA breach has hit the news and drawn much attention. This time, DigiNotar was the compromised CA. [3] Initial reports centered on a fraudulent certificate for Google.com [4][5] encountered by users of Google's services in Iran[6], but information about the scope of the compromise quickly grew. An independent audit of DigiNotar's systems [7] confirmed a large-scale breach. At least six CAs operated by DigiNotar are known to have issued fraudulent certificates, while another twenty-four showed signs of compromise but are not known to have been misused. Over 500 fraudulent certificates have now been identified [8], including popular web properties belonging to Microsoft, Google, Yahoo!, and Facebook. Other certificates target intelligence agencies such as the CIA, MI6, and Mossad. Some certificates even act as wildcards for broad top level domains, such as *.*.com.
Response from web browser manufacturers has been swift and thorough. For the first time ever we're witnessing the 'CA death penalty' with major browsers removing DigiNotar's CAs from their trusted root list. Patches are available for Google Chrome[9], Mozilla Firefox[10], and Microsoft Internet Explorer along with Windows[11]. Apple has drawn criticism for being slow to help protect OSX and Safari users [12], but has also recently released patches[13]. Adobe is in the process of removing the DigiNotar CA from the Adobe Approved Trust List (AATL)[14]. Smartphone updates pose unique challenges [15] and affected devices may continue to be vulnerable for some time.
However, another class of device exists that may also terminate encrypted connections and accept DigiNotar's certificates as valid and trustworthy. I'm referring to a type of system that can broadly be called SSL interception proxies. Traditional URL Filtering, network-based malware scanning, Intrusion Detection and Prevention Systems (IDS/IPS) and Data Loss Prevention (DLP) technologies have historically been blind to encrypted traffic. To address these shortcomings, SSL interception proxies terminate two encrypted connections, the first with the server where it acts as client, and the second with the client where it acts as server. To re-encrypt traffic, these systems leverage their own private CA to sign certificates for the destination sites when they're acting as the server side of the connection. This leaves encrypted data available on the device in clear text, where inspection can be performed. From a technical standpoint, this is essentially a man-in-the-middle (MitM) attack against the end-to-end encryption provided by SSL; the key difference is in the benign intent. A connecting client must be configured to trust this CA fully, or the end user will receive warnings from all encrypted sites.
This re-writing of certificates causes some interesting side effects. A client connecting through an interception proxy can no longer independently verify the identity of a remote web site, nor the identity of the Certificate Authority that issued the remote server?s certificate. These outcomes lead to a situation we call 'transitive trust.' Just like in math when we state the transitive property of 'if a=b, and b=c, then a=c', we can make a similar transitive statement about trust relationships: 'if the client trusts the proxy, and the proxy trusts the server, then the client trusts the server.' In a case where the proxy trusts a certificate that the client wouldn't directly trust, the client is left blindly accepting the connection as valid by means of this transitive trust. This phenomenon has been rarely discussed publicly and may not be well known [16].
Figure 1. SSL proxy and transitive trust.
In short, even a client that no longer trusts DigiNotar's certificates as valid might be connecting to sites using these certificates if the interception proxy still trusts DigiNotar.
Figure 2. Correct behavior ? direct trust rejected by client.
As a result, it's important to consider your environment and any devices that may be active as SSL termination points, even if they aren't the ultimate endpoint, when considering a response to issues such as this. Take the time to review the roots of trust accepted by such devices, and whether they support Certificate Revocation Lists (CRLs) and Online Certificate Status Protocol (OCSP) revocation mechanisms. Updating these devices to revoke misplaced trust, whether by manually removing CAs or by installing vendor-supplied patches, is a necessary and easily overlooked step.
____________
[2] http://blogs.comodo.com/it-security/data-security/the-recent-ra-compromise/
[3] http://www.vasco.com/company/press_room/news_archive/2011/news_diginotar_reports_security_incident.aspx
[4] http://pastebin.com/ff7Yg663
[5] http://pastebin.com/SwCZqskV
[6] http://www.google.co.uk/support/forum/p/gmail/thread?tid=2da6158b094b225a&hl=en
[7] http://www.fox-it.com/
[8] http://nakedsecurity.sophos.com/2011/09/05/ssl-certificate-debacle-includes-cia-mi6-mossad-and-tor/
[9] http://googlechromereleases.blogspot.com/2011/09/stable-channel-update.html
[10] http://www.mozilla.org/security/announce/2011/mfsa2011-35.html
[11] http://www.microsoft.com/technet/security/advisory/2607712.mspx
[12] http://www.pcworld.com/businesscenter/article/239682/apple_silent_on_diginotar_certificates_hack.html
[13] http://support.apple.com/kb/HT1222
[14] http://www.pcworld.com/businesscenter/article/239607/diginotar_certificates_are_pulled_but_not_on_smartphones.html
[15] http://blogs.adobe.com/psirt/2011/09/update-on-diginotar-and-the-adobe-approved-trust-list-aatl.html
[16] http://isc.sans.edu/diary.html?storyid=11533