Trustwave admits crafting SSL snooping certificate

Certificate Authority Trustwave has revoked a digital certificate that allowed one of its clients to issue valid certificates for any server, thereby allowing one of its customers to intercept their employees' private email communication. The skeleton-key CA certificate was supplied in a tamper-proof hardware security module ( …

[Anonymous Coward]

They were being honest. Were they the only ones?

What about the 650-odd other CAs in the list? None of them ever did any of that? Not even for "certified secure, honest" black box DLP systems? Never evar? Really?

On a tangential note, it would be quite useful to have a signed-by-a-CA certificate that allows you to generate certificates for your own domains at will, only you won't get that because a) it wouldn't make CAs as much money as you ponying up hundreds of dollars for each of your (sub)domains, and b) exactly this problem of being able to issue anything you like. In fact, I'd say CAs being able to do that is a problem in an of itself, too. So this problem is something to address in any possible successor to this SSL CA hierarchy thing.

In the meantime, a critical constraint that requires subcertificates signed by this certificate to have (one of this list of) domain(s) as parent would be good. That is, if this certificate lists .example.com as a subcertificate constraint then any subcertificate must be for something ending in .example.com. If you want hierarchies, then best leverage what you got. Sheesh.

[Vic]

> a signed-by-a-CA certificate that allows you to generate certificates for your own domains at will

There's no need for such a thing.

You can already buy wildcard certs - so *.my.example.com will be authenticated from a single certificate. This allows you to do anything you like on your own domain, but nothing to anyone else's.

They're overpriced, sure - but that's a commercial problem, not a technical one.

Handing out root CA capabilities is just stupid. All authentication techniques eventually rely on someone being trustworthy - and what we're seeing here[1] is that many of those "someones" simply aren't.

Vic.

[1] Again...

[Anonymous Coward]

Actually, there is.

For the simple reason that indeed, handing out root CA capabilities is stupid, but handing out subcerts is anything but. You don't always want to run all your subdomains on the same machine and putting the same private key on N servers increases the risk of compromise and the impact should that happen, while decreasing your options to contain the damage. So you need a way to separate the various certs, which you could with a restricted subsigning certificate. In fact, with such a thing you could issue certificates that are useful for $domain and can sign only for subdomains to $domain together with the domain sold. At the very least it should suddenly be easier to explain to the tech-illiterate how the system works and when to decide that the "security information" in the toolbar is in fact bogus even though it claims to check out.

You shot the idea down because there's a technical alternative. Thing is, it's not so much a technical need, but an organisational one. The main problems with the whole scam are organisational, and the technical device that we do have, isn't half as useful as it could be. To me it is also quite curious that both are hierarchical systems in design yet the hierarchies are so strangely misaligned.

Of course, the confusing way we have now is far more lucrative for the select 650-or-so, but that disalignment between them and the rest of us, interest wise, is slowly becoming painfully obvious and we finally have to talk about.

[Vic]

Actually,there isn't.

> So you need a way to separate the various certs, which you could with a

> restricted subsigning certificate.

There is no need for a signing certificate.

If you really don't want to share certificates - and I think your assertion that that is a security threat is incorrect - each subdomain (or wildcard set of them) can have N certificates signed in the usual way. Those certificates are installed on the machines serving up those domains.

This is all pretty simple stuff; the only reason to have a signing key is if you're operating a CA. There are many good reasons to operate your own CA - but obtaining a root signing key is only appropriate if you operate a root CA. This is clearly not the case in this instance.

Vic.

[BillG]

They were being DISHONEST

Hmmm... I wonder. I wonder if this was a security flaw that they are covering up by pretending it was done on purpose.

Would you trust Trustwave? Not me.

[Ben Liddicott]

Any organisation can do this for computers where they have admin, no CA required.

Just make a root and intermediate CA certificate using OpenSSL, deploy to a tricked-out transparent proxy server, and push into the trusted certificate lists of the computers using whaterver remote management you use internally.

IIRC, there exist WAN accelerators which do exactly this to allow them to compress/cache contents of encrypted connections.

Don't use work computers for personal use, people.

[Ken Hagan]

Re: Any org can do this

If the end-user cared to check the certificates (I think all browsers let you do this, at least on desktop PCs) then wouldn't the signing chain make it pretty obvious that something was up? I mean, if I see "Google, signed by <my-local-server>", I'm not really going to think that Google saved a few hundred bucks by asking *my* sys admin for cheap certs.

"Don't use work computers for personal use, people."

Well, not if your employer specifically forbids it, as appears to have been the case here. OTOH, many employers are quite tolerant of "reasonable use".

[Chris Miller]

@Ken

You're correct, of course, but I don't think many 'typical' users would do so (lots of mine wouldn't bother even if they got a big red warning message saying 'security broken'). Life's too short to go around checking every TLS connexion you open.

[Anonymous Coward]

Our policy says

Personal use is not forbidden but is monitored. So that seems to cover this.

[Anonymous Coward]

Depends where you live.

EU right to privicy laws override any micky mouse document knocked up by a HR department.

Quote from f-Secure

"Courts in the United Kingdom have refused to make a distinction between private and professional communication. Because of this generous view of workers’ rights and EU’s Data Protection Directive, European employers must not only be completely transparent about any surveillance, they also have to prove that their surveillance is both legitimate and limited."

[HeNe]

Was the policy statement a lie-by-omission?

If the company gives employees a written statement saying, "We monitor employee email/webmail", and they do ONLY THAT, then the employees have been fairly warned.

But if management or IT/security boffins then ALSO see employees' banking details by MitM-ing "SSL secured" web sessions to employees' banks, management has lied by omission, and should be prosecuted for relevant computer-crime offenses.

If, instead, the written statement said, "We monitor all employee email and on-line activities", then the employees been fairly warned, and management should be off the hook.

I don't use company computers for personal biz... just because.

[phuzz]

The WebMarshal proxy software does this.

[Jusme]

So basically...

SSL encryption is bust, broken and not to be trusted. If the good guys have admitted to having a skeleton-key CA certificate, you can bet the bad guys have them too...

[Vic]

> SSL encryption is bust

No, it isn't.

What is bust is the illusion that all those CA companies are in any way "trustworthy". But any auth system you might think up eventually comes down to trusting *someone*, so this is orthogonal to SSL.

What we need, IMO, is some competition - have a ranking system for the CAs, and have them promoted/demoted such that poor behaviour gets them removed from the trusted list. But I don't know how to build that in such a way that it can't be gamed by a suitably-motivated organisation...

Vic.

[Ken Hagan]

They weren't even being dishonest in the first place

"Trustwave [...] supplied technology that enabled third parties to issue arbitrary SSL server certificates"

That's pretty much what any *root* certificate authority does, isn't it? The only real difference is that Trustwave secured their technology so that the delegated authority could only operate within a limited network.

[Muckminded]

I'll go first

SSL = Say "Security" and Laugh

[Frank Russo]

Why involve a CA at all?

Why would an enterprise need to involve a public CA for web snooping? In 10 minutes, an admin could create his own CA using subject/Issuer information identical to Verisign. He would then roll out the spoofed CA to the truststores on corp assets (your workstation), place the cert on the corp's proxy, and use the proxy to snoop. The users wouldn't see a warning, since their browser/e-mail client trusts the bogus CA already. If the user got curious and clicked on the browser's padlock icon (or moused over it) he would see verisign's information. Only the serial and hash would differ.

Basically, a legit admin would have no reason to obtain a certificate or device as presented in the article because the admin already has access to the client's CA truststores and the proxy. The only systems that could not be snooped would be devices that were not owned by the enterprise or accessable to the admin (if a client device is BYOD). He wouldn't want to undertake the latter, as it would/should put him in jail, which is where the admin and CA should be right now, having openly admitted to a crime.

Intentionally intercepting secure communications between devices you do not own is a crime. Saying "I'm Sorry, we were misguided" afterward doesn't fix things. It is as if your post man read all of your mail with the permission of the postmaster and then said "I'm sorry".

[P. Lee]

indeed

That's the normal way of doing things.

Roll out a "trusted CA" cert to all corporate managed clients.

Force all traffic through a proxy which decrypts and re-encrypts the data. Use client cert authentication so no company cert, no access via the proxy. Because the cert is trusted by the client it will happily give users the illusion that they have end-to-end SSL encryption to their bank. Only installing a browser which doesn't trust the cert will alert you that something is wrong.

So yes, don't use company kit for personal use. If you don't control the hardware and the software, you have no security.

You could introduce multiple tunnels and proxies but its easier to have your own 3g usb or wifi link.

[Vic]

> He would then roll out the spoofed CA to the truststores on corp assets

The point of this fiasco appears to be that they were trying to snoop on *all* traffic - including that on privately-owned equipment.

There might be some legal basis for this - it is their network, after all - but there's certainly nothing ethical in there :-(

Vic.

[Anonymous Coward]

The issue is not that you can fake SSL

It's that someone "trustworthy" was doing it and that there was no way of detecting this.

I don't really have a problem with companies snooping ssl internally, but they should make it quite clear to employees that encrypted connections will be examined. There is no need to hide it.

Its the obviously underhandedness which is worrying.

[Anonymous Coward]

This is not the same as proxy MITM

Yeah yeah we know how proxies and other content inspection systems bust SSL on devices that the organisation owns (by pushing out trust for the CA on the inspection device) but read the article

"revoked a digital certificate that allowed one of its clients to issue valid certificates for any server"

Valid in this sense is valid trusted by all devices due to built in support for trust of certificates issued by that CA. So straightaway all devices on the network are being transparently MITMd - not just those under management.

The whys and wherefores of personal devices on a corporate network aren't for discussion here. What is for discussion is that CAs are dishing out skeleton keys which are neither offline nor in control of the CA so there's plenty of potential for things to go horribly wrong (as per a badly managed CA like Diginotar). Sure there's mention of HSMs and an audit but this is one more nail in the coffin for the current approach.