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…

Filed Under: , , , , ,
Companies: trustwave

Rate this comment as insightful
Rate this comment as funny
You have rated this comment as insightful
You have rated this comment as funny
Flag this comment as abusive/trolling/spam
You have flagged this comment
The first word has already been claimed
The last word has already been claimed
Insightful Lightbulb icon Funny Laughing icon Abusive/trolling/spam Flag icon Insightful badge Lightbulb icon Funny badge Laughing icon Comments icon

Comments on “Trustwave Admits It Issued A Certificate To Allow Company To Run Man-In-The-Middle Attacks”

Subscribe: RSS Leave a comment
30 Comments
Josh in CharlotteNC (profile) says:

Likely has happened before without becoming public

On top of that, there’s no telling if other certificate authorities are doing the same thing elsewhere, significantly compromising SSL security.

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.ars

More details:
http://arstechnica.com/business/news/2012/02/critics-slam-ssl-authority-for-minting-cert-used-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

Anonymous Coward says:

“Trusted Authority.”

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?

LiamO (profile) says:

I can see why companies would want to be able to man-in-the-middle outbound connections from their own corporate network. SSL/TLS can be used to tunnel… well anything really. A malware C&C channel, a way to exfiltrate corporate data etc.

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?

Anonymous Coward says:

Re:

I disagree a system with no trust probably is not going to be useful, the real problem is who do you trust and for what purpose.

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.

Josh in CharlotteNC (profile) says:

Re:

You’re joking, right? People designed the certificate system. Any good security system needs to take into account that people are fallible.

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.

Anonymous Coward says:

Certificate Patrol

A Firefox add-on which helps here is Certificate Patrol, which warns you when a SSL certificate has changed (or when you first see a SSL certificate).

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.

dcee (profile) says:

Re:

And there are over 600 organizations which can sign certificates, including the government of China

Does a normal Windows computer trusts those certificates by default? This is a bit scary if it is.

Just wait until a major application wipes out a notable CA’s “trustbits” – all sorts of hell will break loose.

Can you elaborate on that? I don’t understand what that means but seems quite interesting.

Joseph Durnal (user link) says:

Re:

LiamO has it right. Many of the medium to large businesses and government agencies I’ve worked with use SSL proxies. The reasons for this make sense, preventing or detecting the entry of malware and also to detect or prevent data leaks.

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.

Josh in CharlotteNC (profile) says:

Re:

Does a normal Windows computer trusts those certificates by default? This is a bit scary if it is.

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.

John Fenderson (profile) says:

Re:

“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”

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.

ltlw0lf (profile) says:

Re:

That is why people should not trust the cloud for anything critical.

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.

Jeffrey Walton says:

Violation of US Federal Law?

Evading computer security systems and tampering with communications are violations of federal law in the US. So says the US Attorney General in New Jersey when he charged Wiseguys Tickets with gaming the TicketMaster systems [1,2]. If the Attorney General is to be believed, Trustwave (et al) violated 18 USC 1030 (a) (4) and 1030 (c) (3) (a).

[1] http://www.wired.com/threatlevel/2010/03/wiseguys-indicted/
[2] http://www.wired.com/images_blogs/threatlevel/2010/03/wiseguys-indictment-filed.pdf

nasch (profile) says:

Re: A little help?

How do I go about putting self-signed https on my website without my visitors’ browsers complaining that it’s “insecure”?

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.

Add Your Comment

Your email address will not be published. Required fields are marked *

Have a Techdirt Account? Sign in now. Want one? Register here

Comment Options:

Make this the or (get credits or sign in to see balance) what's this?

What's this?

Techdirt community members with Techdirt Credits can spotlight a comment as either the "First Word" or "Last Word" on a particular comment thread. Credits can be purchased at the Techdirt Insider Shop »

Follow Techdirt

Techdirt Daily Newsletter

Ctrl-Alt-Speech

A weekly news podcast from
Mike Masnick & Ben Whitelaw

Subscribe now to Ctrl-Alt-Speech »
Techdirt Deals
Techdirt Insider Discord
The latest chatter on the Techdirt Insider Discord channel...
Loading...