There are a number of choice quotes, but my two favorites are from Jacob Applebaum (@ioerror if you aren't already following him):
"TrustWave needs to be congratulated and as a reward, I think they should have their CA distrusted."
And another commenter 'Philip' (sorry I don't lurk there and don't have more detailed identity info for him...his words more than stand alone though):
"Trustwave appears to issue certificates directly from its root - this is not good practice. The root should be kept offline and never - ever - have a path to the internet."
...
"the trust chain was broken at the root level, so that is where this branch, and all leaves, must be pruned"
So I guess this is where I break slightly from tptacek's opinion: I'm not yet 100% convinced that the issuance of CA=YES certificates by public CA's is an abusive practice.
Installing organization-specific self-signed roots in all company devices is more than just 'a pain'; it's fundamentally impractical for any organization that wants to let employee-owned or public devices onto its network. So just don't do that? Or just put all the uncontrolled devices onto some airgapped public network? Well, airgapped according to whom, and as of what last physical audit date? Should all organizations that implement DLP have physical security measures similar to DoD installations, where a guard with a gun makes it clear that your iPad should be left locked in your car in the parking lot?
Not saying everything's cool, just saying "it's complicated." What is clear is that Trustwave added at least a couple extra layers of supreme jackassery in this case.
Trustwave's issuance of a CA=YES certificate directly from their topmost root is the most distressingly unprofessional method they could have chosen. That choice alone, in my view, is a coherent argument for why a) their root should be distrusted, and b) they deserve (at minimum) a long cool-down period before an alternative Trustwave root CA becomes a candidate for addition to the default trusted set.
Companies already do device-by-device interventions for all sorts of other security policy issues, from making sure machines aren't going to spread malware to ensuring that USB drives can't be used to exfiltrate data. If a company's employees want to bring their own devices on-site, they can have the company's root cert installed; that's the cost of using your own device on the company's network. That's not an unprecedented policy.
...and it doesn't even matter if the employee-owned devices don't have the employer CA certificate installed; their traffic still gets MITMed and DLPed just fine. It's just that they don't get an (incorrect) indication that their session hasn't been MITMed, which if it is a problem at all, is a problem for the employee.
There are lots of applications that use HTTPS under the covers that will break if certificate validation fails, so not having the root cert installed does "break" those devices.
(There are unfortunately even more apps that use HTTPS under the covers that appear not to care whether certs validate).
> Installing organization-specific self-signed roots in all company devices is more than just 'a pain'; it's fundamentally impractical for any organization that wants to let employee-owned or public devices onto its network. So just don't do that?
Yes, just don't do that. There are sufficient mechanisms to distribute security policy configuration to company devices.
Silently sniffing traffic from external, personal devices is unequivocally unacceptable. I would be livid to know that a company was silent pretending to be my bank, my e-mail provider, or even just Amazon without my prior consent. Having to explicitly trust their internal CA is exactly how that consent is supposed to be provided.
The CA system's trustworthiness is fundamentally broken. I am austounded that Mozilla did not immediately remove the CA certificate from the trusted set.
Company's network, no privacy, full stop. Pick your battles. The problem isn't that a company wanted to MITM SSL traffic on its corporate network. The problem is that a CA was willing to allow them to hijack the whole CA system so they could do it on the cheap.
I think you either misread, or I was unclear -- we're in agreement.
Company network with company devices: sniffing traffic is fine, insofar as it's done by configuring the devices with a private CA.
Company network with personal devices (including visitor's devices): silently MITMing SSL using forged certificates and a real CA is not fine. They can either forbid the use of personal devices, or request that I install their internal CA.
https://bugzilla.mozilla.org/show_bug.cgi?id=724929
There are a number of choice quotes, but my two favorites are from Jacob Applebaum (@ioerror if you aren't already following him):
"TrustWave needs to be congratulated and as a reward, I think they should have their CA distrusted."
And another commenter 'Philip' (sorry I don't lurk there and don't have more detailed identity info for him...his words more than stand alone though):
"Trustwave appears to issue certificates directly from its root - this is not good practice. The root should be kept offline and never - ever - have a path to the internet." ... "the trust chain was broken at the root level, so that is where this branch, and all leaves, must be pruned"
So I guess this is where I break slightly from tptacek's opinion: I'm not yet 100% convinced that the issuance of CA=YES certificates by public CA's is an abusive practice.
Installing organization-specific self-signed roots in all company devices is more than just 'a pain'; it's fundamentally impractical for any organization that wants to let employee-owned or public devices onto its network. So just don't do that? Or just put all the uncontrolled devices onto some airgapped public network? Well, airgapped according to whom, and as of what last physical audit date? Should all organizations that implement DLP have physical security measures similar to DoD installations, where a guard with a gun makes it clear that your iPad should be left locked in your car in the parking lot?
Not saying everything's cool, just saying "it's complicated." What is clear is that Trustwave added at least a couple extra layers of supreme jackassery in this case.
Trustwave's issuance of a CA=YES certificate directly from their topmost root is the most distressingly unprofessional method they could have chosen. That choice alone, in my view, is a coherent argument for why a) their root should be distrusted, and b) they deserve (at minimum) a long cool-down period before an alternative Trustwave root CA becomes a candidate for addition to the default trusted set.