When Certificate Authority Business Models and Vendor Certificate Policies Clash

A very important “internet trust” discussion is underway that has been hidden behind closed doors for years and in part, still is. While the Comodo, Diginotar, and Verisign Certificate Authority breaches forced discussion and action into the open, this time, this “dissolution of trust” discussion trigger seems to have been volunteered by Trustwave’s policy clarification
, and followup discussions on Mozilla’s bugzilla tracking and mozilla.dev.security.policy.

The issue at hand is the willful issuance of subordinate CAs from trusted roots for ‘managing encrypted traffic’, used for MitM eavesdropping, or wiretapping, of SSL/TLS encrypted communications. In other words, individuals attempting to communicate over twitter, gmail, facebook, their banking website, and other sensitive sites with their browser may have their secure communications unknowingly sniffed – even their browser or applications are fooled. An active marketplace of hardware devices has been developed and built up around tapping these communications. In certain lawful situations, this may be argued as legitimate, as with certain known DLP solutions within corporations. But even then, there are other ways for corporate organizations to implement DLP. Why even have CA’s if their trust is so easily co-opted? And the arbitrary issuance of these certificates without proper oversight or auditing in light of browser (and other software implemented in many servers and on desktops, like NSS) vendor policies is at the heart of the matter. Should browser, OS and server software vendors continue to extend trust to these Certificate Authorities when the CA’s activities conflict with the software vendors’ CA policies?

Researcher and privacy advocate Christopher Soghoian quickly weighed in on the topic and suggested the only power that the browser vendors can wield,
“The most important detail to focus on, is (per comment 12 by Brian Trzupek above) that Trustwave knew when it issued the certificate that it would be used to sign certificates for websites not owned by Trustwave’s corporate customer.

That is, Trustwave sold a certificate knowing that it would be used to perform active man-in-the-middle interception of HTTPS traffic.

This is very very different than the usual argument that is used to justify “legitimate” intermediate certificates: the corporate customer wants to generate lots of certs for internal servers that it owns.

Regardless of the fact that Trustwave has since realized that this is not a good business practice to be engaged in, the damage is done.

With root certificate power comes great responsibility. Trustwave has abused this power and trust, and so the appropriate punishment here is death (of its root certificate).”

But other researchers, like Marsh Ray, are arguing that the voluntary disclosure and policy change should weigh into the decision to the Mozilla decision makers to revoke or not revoke the Trustwave certificates. They suggest that even a phased-in revocation may silence future disclosures.

“Personally, I think Trustwave should be commended for being the first CA to come forward, admit to, and renounce this practice of issuing unrestricted 3rd-party sub-CAs.

When I read Mozilla’s policy, and the CA/B Forum baseline requirements, I see enough wiggle room in there that someone might plausibly claim that some agreed-upon scenarios for MitM certs was not prohibited by the agreement. In fact Geotrust was openly advertising a “Georoot” product on their website until fairly recently.

Those who are advocating Trustwave’s removal from the list would seem to be of the belief that Trustwave was somehow alone in this practice. As I do not hold that belief, I think it would be a mistake to continue to threaten Trustwave and discourage other CAs from coming forward at this time.”

The Mozilla Foundation is taking these statements and the issue openly and seriously. Kathleen Wilson posted “If there are any other CAs with roots included in NSS that have this type of subCA, then they should revoke those subCAs and destroy the HSMs asap.” Regardless, the foundation of trust built on Certificate Authority involvement has been steadily eroded for years. It seems that business models and profits have been scaled out on this grey area in a race to the bottom. Spiderlabs should be commended for the disclosure, but the lacking issuance oversight enabling systematic abuse must be handled differently. In the case of Comodo, the company came clean, didn’t delay or play games with disclosure, and generally tried to improve on the mess, and they issued certs to a quarter of the internet. Were they too big to fail or did they handle the incident properly? Perhaps a bit of both. In the case of Diginotar, they issued very few certs, played games with disclosure and didn’t necessarily cooperate. They are no longer issuing certs.

In the meantime, the ongoing Mozilla debate on how to act on the Trustwave disclosure should give you some food for thought. Knowing that this sort of issuance was “common practice” should give cause for hesitation. CA’s are supposed to voluntarily disclose this activity in the first place to software vendors, or their arguably flimsy audits should change this situation, which hasn’t happened for the near decade in which some took part in this business. Do we have another “Enron/Arthur Anderson” auditing nightmare when it comes to our Certificate Authorities? Consider that Diginotar passed their audits with flying colors. Is there any real accountability for the auditors? Or at least, do you think that the “https://” in your browser means that your encrypted communications aren’t being read because “the PKI’s” implementation is guaranteed to prevent Certificate Authorities profiting from abuse, or at least guarantee to prevent profiting from business models in direct conflict with the browser and software vendor policies to whom they are delivering their certs and extending trust? You may think again.