The Certificate Authority (CA) breaches keep coming. KPN, a large Dutch CA, just announced it has detected malware on key systems but isn't sure that any certificates have been wrongfully issued. There are rumblings about a few more authorities having been breached. Given what we've learned about security practices at Diginotar, it seems inevitable that there are others on the trusted root CA list that will experience breaches.
To take a step back, trusted Root Certificate Authorities essentially vouch for the identity of SSL-protected sites on the Internet. When an attacker successfully compromises a root CA, they gain the ability to issue forged certificates. These certificates, when combined with a DNS attack, can be the basis for a Man-In-The-Middle attack on a site on the Internet. That site that you assume is your bank/email provider/cloud storage/favorite social-network doesn't really have to be. The list of trusted root CAs typically come installed by default within applications that use SSL, such as web browsers. For more information on this topic, check out the Fidelis Threat Advisory on SSL.
One of the interesting responses to this flurry of alarming incidents has been the notion of 'SSL Pinning'. Earlier this year, Google announced that Chrome users could "pin" a domain to a specific set of CAs. Additionally, it looks like Chrome has been updated with "pinned" certificates for Google properties on the Internet. The effect of this is that when a user visits such a site and encounters a fraudelent certificate, a warning will be issued or access outright denied.
This is clearly a response with limitations, including the fact that it's limited to Chrome and web properties owned by Google. A few alternative solutions have been noted and dissected but the fact remains that the systemic ones will take a while to be accepted and even longer to be adopted.
I have nothing but respect for these solutions but I'm going to raid my post from earlier in the year and add a few new thoughts to highlight how these solutions are extremely limited from an Enterprise Security standpoint:
- The primary fallacy is assuming that browsers are the only client applications that connect to SSL-enabled services. My primary system has 4 and possibly more applications using SSL and in their infinite wisdom, each has implemented it's own Trusted CA store. What about my chat clients? What about email clients?
- What about in-house servers that need to connect to servers on the Internet via SSL, say for software updates? They are susceptible to MITM attacks too.
- How does an Enterprise Security team roll out these implementations, such as plug-ins? I'm currently helping a customer sort through distributing the in-house root CA to their Mozilla-heavy environment. I don't think they'd be too enthused about the idea of distributing these plug-ins.
- Assuming your heroic IT team does roll out the plug-in or browser of choice to all of your users, how do you trust that none of the SSL traffic you're seeing at your network edge is from users, applications or services that slipped through the cracks?
- I don't fault Google for putting in a fix for their sites using the browser they develop but there are other sites and other applications that Enterprise Security Teams have to worry about. How does one go about pinning your cloud-based CRM or storage provider on every client system?
- Finally, in every case so far, the damage has already been done by the time a CA breach becomes widely known and the browser vendors take action. Wouldn't you want forensics around this issue to establish if somebody inside your Enterprise has been trying to login to a site that has been MITM'ed?
Any technology solution that allows end-users to be more secure, both in their personal and work capacities, is a good thing. But if it's your responsibility to secure an enterprise, you have to be able to assess if all your users (not just the savvy ones) and systems are operating in a secure manner. In my next post, I'll talk about an alternative approach that gives the Enterprise Security team a powerful set of capabilities with respect to SSL and Certificate Authorities.
Comments