Shared publicly  - 
Who exactly are CAs blinding with “PRIVATE” Transparency Proofs?

As Google’s plan to mandate Certificate Transparency for Extended Validation Certificates (ev ct plan | certificatetransparency) proceeds, a number of CAs who have never been on-board (including Symantec and TrendMicro) have announced that they intend to exercise the option to log all of their certificate as “PRIVATE” – that is, indicating only the certificate’s existence and the base namespace in which it lives, rather than the rest of the details about the certificate.

If you are a customer of one of these CAs, you should ask yourself who is really being blinded – your adversaries, or yourself?

I can see the glimmer of logic, or at least the echo of “best practices” now severely showing their age, in not disclosing all private certificates intended only for use inside the enterprise.  (Although I still maintain that such should be issued off a constrained or non-public authority, and that publicly trusted certificates are public statements.) But logging Extended Validation certificates as “PRIVATE” seems especially absurd.   After all, the entire point of EV is to establish an extra degree of trust for a third party human in your organization’s identity, through additional and costly identity-proofing and inclusion of such information in the certificate.  EV indicators aren’t checked by any software I’m aware of, and don’t create a security barrier in the browser vs. non-EV certificates – they strictly provide visual indications for human customers.

So, by their nature, nearly all EV certificates are intended for public deployment.  I’m not sure what exactly anyone with an EV certificate thinks they should be hiding from a public CT log that isn’t easily discoverable in a scan of public network endpoints.

 But even if we assume that you are for some reason deploying an EV certificate in your internal network – what do you have to fear from transparency?  It has long been common practice in network security to limit information disclosure and the reconnaissance abilities of your adversaries – disabling DNS zone transfers and the like - but this conventional wisdom is showing its age.  For one thing, it was never terribly realistic.  An adversary with the barest foothold in your network, or even proximity to one of your roaming machines, is probably going to be able to discover important server names with great rapidity.  Name resolution is a bootstrap process by its nature, so it’s difficult to secure.  A domain-joined Windows box broadcasts the names of domain controllers and anything else it tries to contact all over the network. Even DNSSEC provides integrity but not privacy.  And one set of ordinary-user-level creds is often enough to enumerate the enterprise directory unless you’ve taken unusual precautions. It’s just a losing battle.  And any system that really needs a certificate from a public authority is one that has heterogeneous connectivity and will therefore be difficult to hide. (If you really, really need to keep a server secret, you can probably get by with a privately-issued certificate, since by definition you control the set of clients connecting to it.)

If this battle of secret names were cheap to join and cheap to lose, that might be fine.  But blinding yourself to the credential graph and activity in your network by logging all your certificates as “PRIVATE” is potentially a heavy cost to pay.  You haven’t denied your adversary much at all, and you’ve given them considerable cover in using one of the most powerful assets they can capture and control.   

You may think you have a complete view of the certificates inside your enterprise, but I’d wager that you probably don’t.  Even organizations that have deployed certificate asset management systems rarely find them to be accurate or comprehensive – many are simply based on network crawls.  And such systems are usually connected to the same credential graph that adversaries in your network are already exploiting.  If a sophisticated attacker has compromised credentials to your in-house or external CA that allow them to issue new certificates, they probably can use those same credentials to alter the inventory and logs.   If that attacker then deploys a rogue certificate against your external customers, is your tool ever going to notice it?  If your external CA is compromised or compelled to issue certificates in your name to attack your customers, can your internal inventory system detect that?  Even the “red flag” situation where “a certificate exists somewhere under my namespace that isn’t in my inventory” is simply too common to trigger much alarm, and too vague to take concrete investigative action against.

 So if your CA is telling you that it will be logging all of your certificates as “PRIVATE”, you should ask why, and you should talk to another vendor.  They’re undermining your visibility into the actions of your adversaries, they’re undermining your visibility into compromise, malfeasance or abuse by the CA, and you’re undermining your customers ability to fully trust your services, and for scant benefit indeed.
Ryan Sleevi's profile photoDavid Ford (FirefighterBlu3)'s profile photo
Add a comment...