Trustwave Admits It Issued A Certificate To Allow Company To Run Man-In-The-Middle Attacks
from the wow dept
We've pointed out for years that the whole structure of SSL certificate-based security is open to attack via man-in-the-middle attacks... if you can somehow get a certificate authority to grant you a fake certificate. Of course, the protection against that was supposed to be that a certificate authority wouldn't do that. But what if one did? Certificate authority Trustwave has admitted that it issued a certificate to a company that allowed it to issue "valid" certs for any server. Basically, it gave a company the ability to do any kind of man-in-the-middle attack it wanted on employees. Trustwave has admitted to all this after revoking the certificate. They insist that the structure was limited so that it could only be used internally on the network. But, while it was out there, it basically allowed this company to effectively spy on employee activities, allowing the company to do man-in-the-middle attacks, as employees logged into private ("encrypted") accounts from their own devices, and see what they were doing. Considering this certificate was issued for "loss prevention," it's not hard to guess how it was used.Either way, it's pretty scary that Trustwave would think it was a reasonable move to allow this kind of activity, no matter how carefully the company believes it was set up. In a world where people have perfectly valid reasons for using private personal internet services from the workplace, they should be able to trust that those connections are secure. Thanks to Trustwave's deal with this (unnamed) company, that was not the case. On top of that, there's no telling if other certificate authorities are doing the same thing elsewhere, significantly compromising SSL security.
In the end, this is a significant reminder that certificate-based security systems have serious weaknesses, and that the certificate authorities might not always be trustworthy...
Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.
Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.
While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.
–The Techdirt Team
Filed Under: certificate authorities, man in the middle, privacy, secure certificates, security, ssl
Companies: trustwave
Reader Comments
Subscribe: RSS
View by: Time | Thread
If your life depended on it I wouldn't trust a third party to have my best interests at heart.
[ link to this | view in chronology ]
Re:
It really depends on what you are using the cloud for. If you are running multiple copies of the same critical webserver or other service, then you may be ok. However, if you are putting all your eggs in one basket in the cloud, you're screwed.
I'd tend to use the cloud for things like game servers and xmpp/mumble servers where I can set up a network of devices interconnected with one another and then if one server gets dumped, all other servers are still there. Certainly a lot cheaper than ten dedicated co-loc servers.
[ link to this | view in chronology ]
Three words
[ link to this | view in chronology ]
Likely has happened before without becoming public
I'm not sure if it could be called common, but it is highly suspected by many security professionals that this is not an isolated instance. Why would Trustwave have a specially designed hardware solution that could handle this? Sure, the hardware and software has legitimate uses, but someone from Trustwave really had to configure or program this to function well - and either that means they already had this capability, or spent a lot of effort for this single (yet unnamed) client. Hopefully it will shine a light on other CAs doing the same thing.
While Trustwave's original actions are very distasteful, I do have to give them credit for coming clean. Unfortunately, revoking the bogus cert doesn't really deal with the issue. Certificate revocation is basically the "least bad" option right now. Google has recently said that Chrome may stop checking revocation lists from CAs:
http://arstechnica.com/business/guides/2012/02/google-strips-chrome-of-ssl-revocation-checking.a rs
More details:
http://arstechnica.com/business/news/2012/02/critics-slam-ssl-authority-for-minting-cert-u sed-to-impersonate-sites.ars
Background info on CAs and certificates if you don't understand all this stuff:
http://en.wikipedia.org/wiki/Certificate_authority
[ link to this | view in chronology ]
Re: Likely has happened before without becoming public
https://bugzilla.mozilla.org/show_bug.cgi?id=724929
Brian Trzupek appears to be from Trustwave.
[ link to this | view in chronology ]
Re: Likely has happened before without becoming public
[ link to this | view in chronology ]
Re: Likely has happened before without becoming public
[ link to this | view in chronology ]
Re: Re: Likely has happened before without becoming public
Chrome's solution is a step forward. It solves two problems - websites reluctance to use SSL due to speed concerns, and DoS attacks that would prevent a browser from checking the status of a cert.
There are many other problems that need to be dealt with.
[ link to this | view in chronology ]
[ link to this | view in chronology ]
Any security system based on trust is inherently flawed because it assumes that some authority is trust-worthy. There is no historical support for that assumption.
The DEFINITION of a Trusted System, according to Microsoft and the US Department of Defense, is a system that is permitted to BREAK your security settings.
Do you really want ANY other system to have that power over you?
[ link to this | view in chronology ]
Re:
There is no reason to trust a human with security, but you can trust a machine to do it because you know it will not do something it was not told too and you can check it and it won't try to stop you or lie to you.
Also there is one little fact that nobody could solve yet, in a large group of people if you don't trust them you can't work with them is that simple you at some point will have to give them access to something so they can work on it and you have to trust them not to screwed up.
The best security is the security that doesn't need to exist, whatever reasons it is causing a security concern need to be addressed and the systems designed to be resilient to bad actions or mistakes which probably is impossible currently.
[ link to this | view in chronology ]
Re: Re:
Actually, you can.
The trustworthiness of a person is not black-and-white. If you look at it that way, then nobody on this planet is trustworthy. It's not even a sliding scale.
Everyone I know (including myself) is trustworthy with some types of things and untrustworthy with others, and to varying degrees. When I say that I "trust" someone, what I mean is that I feel I have a good handle on what sorts of things I can trust them about, and what I can't.
The problem with the CAs is that you are placing an enormous amount of trust in an entity without any idea of what you can trust them about and what you can't.
Personally, this means I trust none of them. For my own encryption needs, I run my own root CA. Since I run it, I trust it. But then, I'm a great big nerd.
[ link to this | view in chronology ]
Re:
Right, by "trusted computing" they mean "a computer we can trust to obey our DRM despite the owner's wishes".
[ link to this | view in chronology ]
However, the correct way to implement this is the exact opposite of what Trustwave has done. An SSL proxy like Bluecoat achieves the above goal of MITM'ing corporate SSL sessions by
1)Installing a new Trusted Root Cert on all corporate PCs
2)Using the key for that Cert to sign a faked certificate for all outbound SSL traffic
This way, traffic is still secure between the client and the SSL proxy (using the new certificate), and between the SSL proxy and the end website (using a normal certificate)
As long as the private key within the SSL proxy remains secure, the system is secure (or securish... an admin from your company with access to the proxy could still sniff your SSL traffic - a good reason not to do your net banking at work)
The important difference between an SSL proxy and the ridiculous decision by Trustwave is the failure modes of the system.
Worst case scenarios:
If a hacker gains access to the private key within Company A's SSL proxy, they can MITM computers that belong to Company A. Fair enough, as it was Company A's security failure that led to the key exposure in the first place.
If a hacker gains access to the private key corresponding to the CA certificate that Trustwave issued, until somebody notices and discloses the key compromise and the certificate gets revoked, the hacker can MITM anyone, anywhere, anytime.
See why it's not as good a solution?
[ link to this | view in chronology ]
Re:
Most have an internal CA which is trusted by the corporate systems or they install a trusted root cert generated by their SSL proxy.
With company issued trusted certificates, it is easy for someone who knows what to look for to know if they can trust their connection or not, but the average end user isn't going to check their cert.
I tell all my friends and family that it is likely that their employers IT department can read all of their online passwords.
[ link to this | view in chronology ]
People are the problem, not the system.
[ link to this | view in chronology ]
Re:
Paraphrasing Churchill:
Many forms of security have been tried, and will be tried in this world of sin and woe. No one pretends that the certificate system is perfect or all-wise. Indeed, it has been said that the certificate system is the worst form of security except all those other forms that have been tried from time to time.
Seriously, though, there are some fundamental problems with the certificate system that are not directly human-based. One big issue is that once you trust a CA, you're stuck trusting them forever (in practical terms). Just because I trust Trustwave, or Comodo, or Verisign, now doesn't mean they'll still be trustworthy in 5 years - yet the system really doesn't deal well with revocation of an entire CA. And there are over 600 organizations which can sign certificates, including the government of China. This story isn't over yet. Just wait until a major application wipes out a notable CA's "trustbits" - all sorts of hell will break loose.
[ link to this | view in chronology ]
Re: Re:
Does a normal Windows computer trusts those certificates by default? This is a bit scary if it is.
Can you elaborate on that? I don't understand what that means but seems quite interesting.
[ link to this | view in chronology ]
Re: Re: Re:
I wish I could give you a simple answer, but there isn't one. Some root certificate authorities are trusted by default, yes, and they are generally the big names like Verisign, Thawte, Equifax, GoDaddy and such. But just because you trust a root CA doesn't mean you trust all certs they have issued. There are also intermediate certificates. And then also resellers and affiliates who also issue certs.
Confused yet? It's about to get worse.
Can you elaborate on that?
This is what happened to DigiNotar.
http://www.techdirt.com/articles/20110830/13243615741/evidence-suggests-diginotar-who- issued-fraudulent-google-certificate-was-hacked-years-ago.shtml
They're a small Dutch company that issued certs. They got hacked by suspected Iranian (state sponsored) hackers as a way to monitor secure communications over Google services.
Once the full extent of the breach became known, a lot of their certs were blacklisted, including an intermediate certificate used by the Dutch government for their Tax and Customs Administration. It then became difficult to impossible for Dutch citizens to login to the site and pay their taxes.
That's just a small CA - ramifications were felt by Dutch citizens and whoever in Iran had their Gmail intercepted. What happens if Verisign's CA business (owned by Symantec now) has a massive breach? What if it appears that they were knowingly issuing false certs to a government for the purpose of monitoring their citizens? They control >40% market share. They get blacklisted and that's millions of people unable to login to the bank accounts and investments. Thousands of businesses like Amazon who can't process payments.
[ link to this | view in chronology ]
Insurance?
[ link to this | view in chronology ]
Offhand, I'd say the entire certificate-issuing process needs much more transparency.
[ link to this | view in chronology ]
Re: Anonymous Coward
[ link to this | view in chronology ]
INA , FAG bearing distributor
[ link to this | view in chronology ]
Certificate Patrol
It is not perfect (if you get a new SSL certificate, is "SecureTrust CA" a trustable CA?), and it can generate a bit of noise (yes, Google likes exchanging its SSL certificates a lot), but it can help.
[ link to this | view in chronology ]
[ link to this | view in chronology ]
[ link to this | view in chronology ]
This Is The Way ISA 2004 Worked
[ link to this | view in chronology ]
Violation of US Federal Law?
[1] http://www.wired.com/threatlevel/2010/03/wiseguys-indicted/
[2] http://www.wired.com/images_blogs/threatlevel/2010/03/wiseguys-indictment-filed.pdf
[ link to this | view in chronology ]
A little help?
[ link to this | view in chronology ]
Re: A little help?
I don't know if you're really asking, or if that's rhetorical. So I'll respond both ways. I don't think it's possible to do that. And it might seem stupid, but I think the idea is if the user is browsing unsecure, they're aware of it and accept the risk (stop laughing), whereas you don't want to present a certificate that essentially does nothing to ensure identity as though it's a secure browsing experience.
[ link to this | view in chronology ]