Trustwave admits issuing man-in-the-middle digital certificate (ComputerWorld)

To clarify: it does seem unfortunate to apply this policy to a CA which came forward, admitted the problem, and revoked the certificate in question. However, given the *huge* amount of trust placed in CAs, and that the issuance of this certificate blatantly violates any and all sensible policies for certificate authorities, I don't see how Mozilla can do otherwise.

At a minimum, after clarifying their CA policy with an appropriate amount of "no really"s, CAs need re-validation against the new policy.

> Hopefully this leads to an immediate removal of TrustWave from browser trust roots.

It's not clear what that would accomplish. There are plenty of CAs out there that probably did the same thing, and it seems out of place to punish TrustWave for both proactively revoking these subordinate certificates, and for publicly admitting their existence. More useful might be to say "Every other CA must similarly revoke such certificates by Feb 15; we'll start looking, and if we find any violations after that point, your CA will be immediately removed from the browser trust root forever". But as you say, the fundamental model of CAs is flawed.

I think you've missed the severity of this problem by thinking that browsers should notice this. The CA model allows a trust chain from a certificate to a CA root by way of intermediate certificates, as long as those intermediate certificates have the bits set that allow that use. Among other things, CAs use this so they can store their trusted root offline and only use it to sign an intermediate root which in turn signs user certificates. Some CAs also use it to have various subsidiaries which they trust to offer certificates; see the Comodo issue where one of their subsidiaries got broken into.

TrustWave issued an intermediate root certificate, which could then sign any arbitrary certificate in a way that browsers would trust, and gave that intermediate root certificate to a company to MITM its employees. Browsers had no way to notice or warn users about this, unless they used one of the browser extensions that compares SSL certificates with what other people see, or happened to notice that all their SSL certificates came from the same intermediate root of the same obscure CA.

That something is wrong with the CA industry is not a particularly original observation.

As to common practise, I cannot seem to find anything right now, but a company we dealt with in the past is reselling certificates of various vendors, and the offers on their webpage include "root signing", which I understand to be signing of an intermediate CA. Prices for that begin at 10 k€. These seem to be offered for Comodo, RapidSSL and Thawte.

Not everyone is that open with their offers, but I'm pretty sure these are available from many CAs for an appropriate price. The legitimate(?) use case is a company that would rather pay a lump sum to have their MITM device work painlessly, than have to install their self-signed MITM-CA certificate as trusted on every end-user device.

Oh, and Symantec is selling gateways for anti-virus and data leakage prevention. Both purposes would be served well by a SSL-MITM, and probably have one built in (it's state of the art). A CA certificate signed by a generally accepted root CA (like Verisign's) would go fine with that. I am not aware of them doing that.

From my understanding, most of these certificates are placed in networks for 2 reasons:

1) Network security. Many malware programs don't check certificate authenticity but will not be using the certs you plugged into a box even if you owned it. The network security boxes then use those * certs to see what is going on anyway.

2) Personel monitoring. People increasingly bring their own cell phones, laptops and then use the company network. Case law has gone that anything posted there is the responsibility of the company to police.

Whether or not these make "common sense" or not, too many juries have ruled that companies are responsible for that and there is no safe harbour. So basically it becomes a rule that if you are large enough to sue, you better watch everything you can :/

> You don't need a subordinated root of a trusted CA to do it.

Its true that the traditional way of setting up a DLP/firewall/SSL proxy is to use an internal CA that is trusted by the clients, I can only imagine that the customer didn't want the administrative overhead of touching every machine to load certs or had some clients they couldn't touch that they still needed policy enforcement on. Signing a subroot which will be trusted by the majority of clients is a technically easy way around this but clearly even Trustwave agrees that this is a bad idea which is why they have very publicly stopped doing it.

Are you sure Firefox restores them? That sounds strange. Perhaps you are just not privileged enough, and Firefox gives no error message?

> I am dismayed that Mozilla Firefox does not allow one to permanently disable the built-in certificates.

It does. At least Firefox 4.0 on Debian does. Clicking "Edit Trust" allows you to stop trusting the cert for various things, such as "Identifying web Sites". Those settings are remembered across reboots.

You are correct in saying if you delete a cert it re-appears at the next restart, but it reappears with all trust settings disabled.

You may be interested in a blog post by one of the Tor guys about how he does exactly that: https://blog.torproject.org/blog/life-without-ca

You can permanently disable certificates in Firefox. I have done so myself after previous incidents, like Comodo or DigiNotar. You will still have the certificates there, but you can mark them as untrusted.

The problem is, this breaks the web. Unless everyone does it, thus forcing websites to switch certificate providers, it mainly just frustrates you by making you jump through more hoops any time you go to a site signed with one of those certificates. There is no good way to distinguish between "I'm being MITM'd by a compromised cert" and "this website is still using one of the CAs that I don't trust." And while you can click through the warning if the main page is signed by an untrusted CA, it's really hard to fix the problem when it is using resources (images, JavaScript, and CSS) signed by an untrusted CA while the main content is signed by a trusted one; then you don't get a big scary screen to click through and say "yes, this is OK," you just don't get any of the JavaScript or CSS working and have to dig through the site to try and figure out which resources use what CAs and selectively re-enable those.

I've had to go back and re-trust most of the certificates that I had un-trusted, because I just couldn't use Firefox that way.

When used correctly, it's a security feature. CAs keep the long-lived key that the browser trusts (root key) offline, and sign certificates with a short-lived intermediate CA signed by the root key. They only need to take the root key out of storage when the intermediate CA is close to expiring.

The difference here is that Trustwave gave an intermediate CA key to another company rather than keeping control of it themselves.