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


Reader Comments (rss)

(Flattened / Threaded)

  1.  
    identicon
    Anonymous Coward, Feb 8th, 2012 @ 8:02pm

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

    If your life depended on it I wouldn't trust a third party to have my best interests at heart.

     

    reply to this | link to this | view in thread ]

  2.  
    icon
    pixelpusher220 (profile), Feb 8th, 2012 @ 8:18pm

    Three words

    Name. The. Company.

     

    reply to this | link to this | view in thread ]

  3.  
    icon
    Josh in CharlotteNC (profile), Feb 8th, 2012 @ 8:23pm

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

     

    reply to this | link to this | view in thread ]

  4.  
    icon
    fogbugzd (profile), Feb 8th, 2012 @ 8:23pm

    Certificate Authorities make huge amounts of money and the effectively control some important Internet governing and standards committees, so we can expect a huge fight when people realize the system is not nearly as secure as it pretends to be.

     

    reply to this | link to this | view in thread ]

  5.  
    icon
    Josh in CharlotteNC (profile), Feb 8th, 2012 @ 8:47pm

    Re: Likely has happened before without becoming public

    For those inclined, there's a thread on the Mozilla forums about this.

    https://bugzilla.mozilla.org/show_bug.cgi?id=724929

    Brian Trzupek appears to be from Trustwave.

     

    reply to this | link to this | view in thread ]

  6.  
    identicon
    Anonymous Coward, Feb 8th, 2012 @ 8:48pm

    "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?

     

    reply to this | link to this | view in thread ]

  7.  
    icon
    LiamO (profile), Feb 8th, 2012 @ 8:53pm

    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?

     

    reply to this | link to this | view in thread ]

  8.  
    identicon
    Anonymous Coward, Feb 8th, 2012 @ 9:01pm

    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.

     

    reply to this | link to this | view in thread ]

  9.  
    icon
    pixelpusher220 (profile), Feb 8th, 2012 @ 9:09pm

    Re: Likely has happened before without becoming public

    In case anyone wants to remove Trustwave themselves according to comments in the 2nd arstechnica link they are listed under "SecureTrust CA" in your certs list.

     

    reply to this | link to this | view in thread ]

  10.  
    identicon
    Anonymous Coward, Feb 8th, 2012 @ 9:56pm

    The certificate system doesn't have any serious holes or issues.

    People are the problem, not the system.

     

    reply to this | link to this | view in thread ]

  11.  
    icon
    Josh in CharlotteNC (profile), Feb 8th, 2012 @ 10:37pm

    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.

     

    reply to this | link to this | view in thread ]

  12.  
    identicon
    Anonymous Coward, Feb 8th, 2012 @ 10:50pm

    Re: Likely has happened before without becoming public

    According to the link you provided, it seems Google Chrome is just dropping the function to contact for revokation URL and chosen to maintain a central repository of revokation list themselves. So Chrome users can still see this cert got revoked.

     

    reply to this | link to this | view in thread ]

  13.  
    identicon
    Anonymous Coward, Feb 8th, 2012 @ 10:55pm

    Insurance?

    All CAs have bought insurance for damages caused by security breaches at the faults of CAs. Is there anyone claim to be affected by this and claim the money yet?

     

    reply to this | link to this | view in thread ]

  14.  
    identicon
    Anonymous Coward, Feb 8th, 2012 @ 11:25pm

    Checked my trusted root CAs. Three had "Trustwave" in the "Friendly Name" field. Deleted.

    Offhand, I'd say the entire certificate-issuing process needs much more transparency.

     

    reply to this | link to this | view in thread ]

  15.  
    identicon
    Nancy@famousbearing, Feb 9th, 2012 @ 1:24am

    INA , FAG bearing distributor

    INA , FAG bearing distributor

     

    reply to this | link to this | view in thread ]

  16.  
    identicon
    Anonymous Coward, Feb 9th, 2012 @ 1:39am

    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.

     

    reply to this | link to this | view in thread ]

  17.  
    icon
    Josh in CharlotteNC (profile), Feb 9th, 2012 @ 4:47am

    Re: Re: Likely has happened before without becoming public

    Unfortunately its not that simple.

    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.

     

    reply to this | link to this | view in thread ]

  18.  
    icon
    dcee (profile), Feb 9th, 2012 @ 5:22am

    Re: 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.

     

    reply to this | link to this | view in thread ]

  19.  
    identicon
    Joseph Durnal, Feb 9th, 2012 @ 5:54am

    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.

     

    reply to this | link to this | view in thread ]

  20.  
    icon
    Josh in CharlotteNC (profile), Feb 9th, 2012 @ 8:10am

    Re: Re: 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.

     

    reply to this | link to this | view in thread ]

  21.  
    icon
    John Fenderson (profile), Feb 9th, 2012 @ 9:55am

    Re: 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.

     

    reply to this | link to this | view in thread ]

  22.  
    icon
    ltlw0lf (profile), Feb 9th, 2012 @ 11:16am

    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.

     

    reply to this | link to this | view in thread ]

  23.  
    icon
    That Anonymous Coward (profile), Feb 9th, 2012 @ 7:19pm

    Ahoy Trustwave... I am not sure you understand what that word means...

     

    reply to this | link to this | view in thread ]

  24.  
    identicon
    Anonymous Coward, Feb 9th, 2012 @ 9:19pm

    SSL security has been completely defeated, regardless of whether or not "sudo cert" if you will, was ever issued. MITM attacks still happen. SSLSTRIP

     

    reply to this | link to this | view in thread ]

  25.  
    icon
    toyotabedzrock (profile), Feb 10th, 2012 @ 8:10am

    This Is The Way ISA 2004 Worked

    Microsoft's ISA server 2004 intercepts encrypted traffic in the same way. It you have an active directory domain setup it deploys the needed certificate to perform the task.

     

    reply to this | link to this | view in thread ]

  26.  
    identicon
    Jeffrey Walton, Feb 12th, 2012 @ 2:17am

    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

     

    reply to this | link to this | view in thread ]

  27.  
    identicon
    Jeffrey Walton, Feb 12th, 2012 @ 2:21am

    Re: Anonymous Coward

    Try lurking on mozilla.dev.security.policy or the CAB Forums (CA-Browsers). Watching the politics in action is amazing.

     

    reply to this | link to this | view in thread ]

  28.  
    icon
    nasch (profile), Feb 12th, 2012 @ 8:29pm

    Re:

    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.

    Right, by "trusted computing" they mean "a computer we can trust to obey our DRM despite the owner's wishes".

     

    reply to this | link to this | view in thread ]

  29.  
    identicon
    Anonymous Coward, Mar 12th, 2012 @ 1:57am

    A little help?

    So... How do I go about putting self-signed https on my website without my visitors' browsers complaining that it's "insecure"? Browsers never complain when a site is unencrypted, and self-signed encryption can't be any less secure than that!

     

    reply to this | link to this | view in thread ]

  30.  
    icon
    nasch (profile), Mar 12th, 2012 @ 6:32am

    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.

     

    reply to this | link to this | view in thread ]


Add Your Comment

Have a Techdirt Account? Sign in now. Want one? Register here
Get Techdirt’s Daily Email
Save me a cookie
  • Note: A CRLF will be replaced by a break tag (<br>), all other allowable HTML will remain intact
  • Allowed HTML Tags: <b> <i> <a> <em> <br> <strong> <blockquote> <hr> <tt>
Follow Techdirt
A word from our sponsors...
Essential Reading
Techdirt Reading List
Techdirt Insider Chat
A word from our sponsors...
Recent Stories
A word from our sponsors...

Close

Email This