Trustwave's admission that it issued a digital "skeleton key" that allowed an unnamed private biz to spy on SSL-encrypted connections within its corporate network has sparked a fiery debate about trust on the internet. Trustwave, an SSL certificate authority, confessed to supplying a subordinate root certificate as part of an …
Methinks a proportionate response would be to disallow/distrust Trustwave certs in the Mozilla browser for a period of, say, 6 months. This would hurt Trustwave, but not ruin them. And hopefully set an example that will make other certificate issuers weary of pulling similar stunts.
On Allocation of Blame
The problem here is that the people who are inconvenienced are the users of any site with a trustwave certificate. They will note that the website they want to visit appears 'broken' in Mozilla's browser, but fine for everyone else.
They then ditch whatever Mozilla product they were using and presumably switch to Chrome instead. End result? Mozilla's market share drops, the value of their 'SSL Death Penalty' drops, and Trustwave is only mildly inconvenienced.
Thus, unless there is a clear and present danger there is minimal benefit for Mozilla making a unilateral decision to blacklist a CA. This is one of those exciting emergent problems which SSL's developers almost certainly never thought of.
"In addition, it revoked the offending certificate."
And pray what good does that do, given the current implementation state of OCSP?
the same thing the big 4 did to diginotar
They push the revoked certificate into your browser CA list. Check yours, I just did, and it's there, and expired. That way they don't have to rely on OCSP/CRL, they just brute forced it.
Its what Google want to do, which relies on the insidious GoogleUpdater process.
Why was it even necessary?
As this was a single enterprise in control of the PCs, it could have just pushed out it's own trusted root to the machines and installed them on other devices and accomplished exactly the same thing.
The average user wouldn't have been likely to know (if that's what they wanted).
They wouldn't then have needed the expense of using Trustwave.
They would only need a known Trusted Root Authority if they were also spying on visitors or guests using their network (public WiFi?). Which would raise a few more questions...
The only reason to have a "proper" root cert is if you want to be sneaky an pull in people who are not using corporate systems. That's a bit of a hail mary due to the proliferation of personal 3g links which bypass the whole lot.
Either that, or its a very large organisation without the ability to manage its devices' certs. I suppose that isn't too unlikely.
This sort of thing happened to us a few weeks ago ... firewall/security servers started to act as "man-in-middle" on https transaction for "virus/threat checking" with security certificates pointing to the server rather than the real site being accessed. The relevant certificate had already been pushed out to PCs so people using the "corporate IT standards" (i.e. IE) didn't notice but those of use using firefox (and, perish the thought, people using Unix machines) saw warnings of mismatching security certificates. Rapid and juge uproar followed - especially as people in French part of company pointed out that this was probably an illegale wire-tap under French law - and the system was dropped (allegedly for "performance reasons")
Who's next? Symantec/Versign?
I wonder if Vegas is taking bets on the next one to fall?
Don't get fooled
into thinking that if you use a browser besides IE you will get a warning about a certificate mismatch. Furthermore a self signed certificate will accomplish this with no problem. I work for an organization that shall remain nameless and I'm a responsible for administering a transparent proxy server made by Blue Coat Systems that intercepts all traffic including SSL communications. The certificate has been rolled out to people's machines and the only indication that your SSL session is intercepted is by actually looking at the certificates which is always issued by the organization. IE, firefox and Chrome do not ever complain. The only way you can ensure you are not interecepted is by tunneling all your traffic via SSH or similiar mechanism. It's a scary world we live in and I wouldn't trust the broken SSL system one bit.
So, you're saying that when you sign traffic using your cert which isn't in my authentication list in firefox it won't complain at all? Certainly not my experience. Doesn't matter whether the certificate is on user machines or not.
"Trustwave will escape sanction and that other certificate authorities will be given a period of grace to come clean if they are offering MitM technology."
That means everybody's at it.
If it were a telco?
... it would have a profound impact.
That they haven't revealed the identity of the organisation is worrying.
how to defeat this practice?
Without considering the time/effort, what would it take to defeat this snooping? Presumably if the snooping system wasnt able to terminate/decode/etc the traffic, it would drop it, so only those intent on bypassing it would even know.
I've been wondering about that
I reckon it would expose itself by the unusual frequency of server certificates signed by the evil Root CA.
You could then envisage a browser add on that spotted an excess of certificates signed by a common root CA and warned you that you were likely subject to MITM surveillance.
There is only one reliable solution to MITM as far as I'm aware; identify and permanently eliminate the MITM.
and the next firefox add-on is....
a cert chain tester that does what this site: http://www.sslshopper.com/ssl-checker.html does.
that runs for every https site.
If I use sslshopper to check a certificate installation, it shows me the certificate chain from host to CA. Since I'm not a programmer, this is what I'd like in an add-on, albeit in a smaller screen footprint.
As Daf L says, they could have accomplished this for their own users by putting their own root cert on their user's machines. This suggests that they wanted to intercept something other than their employees' communication. Suppose a visitor from a customer or supplier is on site, and is invited to use their WiFi hotspot: very common these days. They would be in a good position to intercept email.
I hope not!
I sincerely hope an organization that needs this kind of auditing isn't running a wi-fi hotspot! Or allowing any unauthorized devices on their network at all... kind of defeats the purpose if it is.
This kind of thing has been going on for a while
Two years ago, when I was on Blackberry, I stayed at a cheap hotel, owned by a well-known chain, in Southampton. I connected my Blackberry to the free wifi offering and it instantly popped up a whole-screen critical security warning that that SSL fingerprint of the Blackberry server didn't match the certificate RIM had issued and warned me that all my traffic was at risk of interception if I allowed the connection.
I don't know if a regular browser would have picked up this MitM attack as I don't know who the signer of the bogus certificate was. I really think Mozilla and Chrome need plugins to detect dodgy/changed certificates.
Secret eavesdropping is illegal in most parts of EU
and punishable by criminal law - you know jail-time and all. I can only imagine one scenario where you could do it legally. In a very big corporation which let's their employees know they are being eavesdropped but is not capable (might be too expensive) of installing their own root-certificates to their machines.
SSL should not cross this line because it is practically impossible for an outsider (Mozilla? Trustvawe?) to determine if the conditions were right for this kind of eavesdropping. Let's leave determining this to the national authorities like police and courts - shall we. If a private company wants to eavesdrop it should pay the price of managing it's own hardware/software and installing it's own root certificates .
I can't remember the last job I went for that didn't make me sign a contract giving them the right to (among other things), monitor what I was doing on their network.
Of course, any company of any size has the ability to push their own root cert to all their client machines, which would have been much cheaper for this un-named customer that presumably paid a lot of money for this 'skeleton key'. Of course, a self signed cert would be obvious to anyone accessing using a third party device, but if they're not an employee, why are they using your internet connection anyway?
True, but you cannot sign away your statutory rights and if said company are seen to have breached RIPA or any other comms/privacy related law then they're fucked. They can monitor your internet usage but they certainly cannot legally MITM your connection to your internet banking. That is interception of communication.
SSL isn't broken by this
It's the current CA/PKI system used with SSL which is broken, not SSL itself. If your application tells SSL to trust a particular certificate authority or certificate, that's exactly what it will do.
At least when I run a SSH tunnel (which also uses SSL)out of my corporate work environment using X forwarding I can display applications run remotely on my secured system displayed locally, and for which I personally get to check the SSL fingerprint of the SSH server. I do similar things with my server's SMTP/IMAP AUTH TLS cert when I setup email clients, and I got suitable warnings on all of them when I changed the TLS private key.
Moxie Marlinspike's Convergence protocol http://www.youtube.com/watch?v=Z7Wl2FW2TcA (long video - but well worth the time spent) shows that at least someone is trying to set something up so that end users don't need to match hex strings to do this job.
But none of this PKI problem (where you can choose usability or security but not both) can ever really be fixed without end to end DNSSEC.
What a shame...
... that there are no vigilante groups out there that will bring them down and inflict some tough justice. Some anonymous heros if you will.
- Boffins attempt to prove the UNIVERSE IS JUST A HOLOGRAM
- China building SUPERSONIC SUBMARINE that travels in a BUBBLE
- Review Raspberry Pi B+: PHWOAR, get a load of those pins
- That 8TB Seagate MONSTER? It's HERE... (You'll have to squint, 'cos there are no specs)
- Review Reg man looks through a Glass, darkly: Google's toy ploy or killer tech specs?