Of CAs, DLP, CSRs, MITM, inspection and compliance
Writing about certificate authorities is slowly turning into beating dead horses. We have seen a couple of security breaches at CAs in the past. We have witnessed security researchers turning to SSL/TLS. Fairly recently researchers have put RSA keys to the test and found common prime factors in thousands of keys. Now we have a discussion about compliance. The Mozilla team has given CAs a stern warning sparked by the issue of a signing certificate by the Trustwave CA to a customer using a data loss prevention (DLP) device. According to a report the signing root certificate was used inside a Hardware Security Module for the purpose of dynamically creating fake certificates in order to inspect encrypted web traffic. While there was an audit at the customer’s site, this incident has sparked a heated debate about the trust end users and IT department place into the use of certificates from CA on the market.
Deploying data loss prevention measures is a well-known problem. Controlling the data that leaves or enters your organisation is quite difficult. Usually encryption stops your countermeasures unless you find a way to decrypt and inspect the transmitted data in question. A straight-forward way of doing this is to create your own CA, deploy you CA’s root certificate to all your clients and terminate the „external“ encryption at your border gateways/proxies. Unfortunately not all devices and computers allow importing „strange“ CAs. This is in part security measure and in other parts broken by design (maybe the vendor does not trust you or want to exert control over the device even after you bought it). What do you do now? In theory you can’t do anything. Unless a „registered“ CA is willing to issue a subordinate root certificate which is part of the chain of trust. You can then break the encryption for inspection, and suddenly all your device are to belong to you, no matter what.
Some questions remain. Does your encrypted traffic flow through one of these inspection devices? Has one of these subordinate root certificates „escaped“ into the wild? The answer? Hard to tell. We’ll probably never know.
2011 featured some spectacular security breaches at certificate authorities. Just remember the DigiNotar case which was handled quite well by the CERTs involved given the circumstances. So, we’re good, are we? No, we’re not. All it takes to damage a centralised trust model is a single incident. We have seen multiple security incidents in the past 12 months, and we most probably do not have the full picture. If you have ever bought SSL/TLS certificates, then you know that there are a lot of players on the market, all with different pricing and security promises. Apart from that there is still the problem of software out there that is not capable of TLS 1.1 or TLS 1.2, and both address a lot of important shortcomings of TLS 1.0 (where the BEAST lives for example). There are no short-cuts, especially if you have to upgrade your infrastructure.
If you have thoughts on centralised trust models, the current state of CAs or ideas how to keep encrypted data transmission secure, you can leave a comment in this blog or submit a proposal for a talk for DeepSec 2012. The latter is preferred.