In my first post, I talked about some of the inadequacies of client-side SSL-pinning solutions that have been proposed since the spate of Certificate Authority breaches this year. Briefly, the key issues are (a) browsers aren't the only SSL-using client applications (b) client systems aren't the only users of SSL (c) plug-ins are great for motivated users but are hard to roll out in the enterprise (d) none of this gives you a forensic view around SSL traffic in your enterprise.
Again, as a diligent and concerned user of technology, I am very careful about my SSL sessions in my personal capacity. I applaud every one of these solutions for assisting me in being safe in my use of this technology. But with my enterprise security hat on, I need more.
I was in a conversation with a customer recently about their use of Application White Listing (AWL) solutions. Something that he pointed out to me was that all the AWL solutions he was looking at weren't very good at detecting applications that didn't get copied to the disk ie. those that ran straight from memory. To mitigate this, he was hoping we could give him insight into contents of executables being downloaded by his users. And luckily enough, we already do, with Flash Action Script inspection also coming soon.
Essentially, he wanted to use his network security stack to give him capabilities around client applications that his client security solutions couldn't do. I'm going to propose something similar for SSL certificates.
Wouldn't it be neat if you could do certificate inspection and configurable SSL-pinning at the network edge?
In practical terms, this might involve the following:
- Examine the certificate on every SSL session that passes through the enterprise gateway
- Build a list of certificate details for the sites that really matter to you - your cloud storage provider, your hosted Sharepoint/Exchange provider, your cloud CRM and even perhaps key webmail and social networking sites.
- Install rules that alert you or block if a session to one of these sites is seen with a certificate that doesn't match the list you built.
I recognize that certificates are meant to be time-limited and need refreshed and pinning them blunts the ability of sites to change certificates at will. What happens when the site provider wants to change Certificate Authorities or simply has them issue new certificates? If you have a business relationship with the provider, if say they were your Sharepoint host, you might have requirements for notifications built into your contract. When they inform you they're changing, change your certificate list.
If you're not in a position to do this, you'd really want to use a device that can alert you, rather than simply prevent such sessions, which might interfere with legitimate business. And then when you saw an alert, dig in and ascertain if the site has actually changed certificates. If their new CA seems to be obscure, it's quite likely you've found an attack in progress.
I also recognize that the Web is a big place and you don't want to be in the business of building a static list for everybody out there. For one, that'd be a maintenance nightmare. This also defeats the point of the trust chain around SSL and Certificate Authorities in general. That's why I'd suggest limiting the list to key sites.
Beyond pinning, the combination of Certificate Inspection and suitable rules logic should give you the ability to alert or prevent future sessions involving sites that have been signed by CAs who are known to have been breached. When you hear about the next Comodo or Diginotar, you don't have to wait for entities like browser vendors to update their Trusted CA lists and push patches out to your users.
Also, this also gives you the ability to do forensics. If you do hear about a CA breach, how do you get your client systems to report sessions from the recent past involving sites signed by the CA in question? If your network solutions do forensics intelligently, it should be a simple report to get that information back to you.
So there it is - SSL Certificate Inspection and Pinning at the network edge. Still not perfect and certainly not a systemic solution. But in my view, this is a practical solution for those of us worried about this issue in the Enterprise.
If you'd like to hear more about SSL pinning and how Fidelis examines SSL certificates allowing users to build policy around certificates and authorities, please plan on attending our December 15th webinar—The False Sense of Security: SSL Visibility and Decryption on the Network Edge--with guest speaker Andrew Hay from the 451 Group and myself, register at www.FidelisSecurity.com/webinars.
Comments