Slashdot Mirror
Controversial Surveillance Firm Blue Coat Was Granted a Powerful Encryption Certificate (vice.com)
Joseph Cox, reporting for Motherboard (edited for clarity): A controversial surveillance company called Blue Coat Systems -- whose products have been detected in Iran and Sudan -- was recently issued a powerful encryption certificate by Symantec. The certificate, and the authority that comes with it, could allow Blue Coat Systems to more easily snoop on encrypted traffic. But Symantec downplayed concern from the security community. Blue Coat, which sells web-monitoring software, was granted the power in September last year, but it was only widely noticed this week. The company's devices are used by both government and commercial customers for keeping tabs on networks or conducting surveillance. In Syria, the technology has been used to censor web sites and monitor the communications of dissidents, activists and journalists.Blue Coat assures that it is not going to utilize the certificates to snoop on us. The Register reports: We asked Blue Coat how it planned to use its new powers -- and we were assured that its intermediate certificate was only used for internal testing and that the certificate is no longer in use. "Symantec has reviewed the intermediate CA issued to Blue Coat and determined it was used appropriately," the two firms said in a statement. "Consistent with their protocols, Symantec maintained full control of the private key and Blue Coat never had access to it. Blue Coat has confirmed it was used for internal testing and has since been discontinued. Therefore, rumors of misuse are unfounded."
"Blue Coat assures that it is not going to utilize the certificates to snoop on us."
Oh, heaven forbid, I'm sure any concern about this is just due to paranoia.
No way anyone would ever misuse power like this, and certainly not a company that sells web-monitoring software. Why, the very thought is just too silly to contemplate!
*cough*
Just cruising through this digital world at 33 1/3 rpm...
If they were using it for internal use, and all the PCs they were using it with were under their control, they could have easily made their own certificates that would be limited in use to their own PCs only. So why ask for a certificate that can spoof any website and will be trusted by every PC?
I'd say the Symantec root CA should be removed from browsers. Only substantial action will teach them to take their great responsibility as a CA seriously.
Simple answer, because the tinfoil hat club has been proven right over and over again in the 21st century.
Sad but true.
I had a scheduled job interview with Blue Coat when I got three job offers from other companies and went elsewhere two years ago. I wasn't aware that were such a shady outfit. I'm happy I didn't get a job with them.
not real security anyway. it may suffice for everyday mundane purposes for the little people, but people who need real security all use self-signed certificates and the corresponding cumbersome process to exchange them.
I don't think that the tinfoil hat club has been right. In fact, the surveillance and control has been worse than most claims of the tinfoil hat club.
The real "Libtards" are the Libertarians!
if your NSM can't see SSL then you don't have NSM.
It's the other way around: if your SSL doesn't protect you from some crap MITM box, then you don't have SSL.
If you say that a company should be able to snoop on all connections of their employees, that's trivial to do. Just install the company's CA root on every employee's machine. But you want to do this to innocent third parties, don't you? Tough cookies then. I see no legitimate reason for SSL interception without the owner's consent. Ever.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
Symantec maintained full control of the private key and Blue Coat never had access to it.
Someone doesn't understand public key encryption at all.
Without the private key, the public key is of absolutely no value to Blue Coat.
They use the private key to sign other keys or to simply put themselves in a Man In The Middle scenario without being easily detectable (you'll get no warning visiting www.google.com even if they are spying on you thanks to Symantec)
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
This story isn't about Bluecoat per se, it's a story about Symantec selling out our trust - I have no reason to believe that they have not sold out to so to many other companies and regimes and organizations beside Bluecoat.
For a company that trades on being trustworthy they sure know how to destroy confidence.
Nullius in verba
"The Treadstone Project has actually already been terminated..."
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
There are over 650 entities across the globe that can sign SSL certificates for any domain they want. For less than 6 figures USD you can buy an intermediate cert yourself. Not to mention that unless you ask for something like google.com or something similarly high profile, you can just *buy* a site certificate for sites you don't own from less-than-thorough CAs.
How is it special that Bluecoat can sign their own (maybe - assuming Symantec is not to be believed on who had the keys)? Most of the government actors they sell their products to *already* have their own CA that OSes and browsers trust, and thus can just use their own.
The global CA system is a hopelessly broken part of SSL for web sites (SSL is fine in general, and if you're using it to secure your own sessions with your own certs, everything is basically good otherwise), and being shocked about some non-story is not helping. Using SSL on the web means that you have placed permanent and absolute trust in everyone who controls a root, and everyone who they ever issued an intermediate signing cert to. That's not sane.
If they were using it for internal use, and all the PCs they were using it with were under their control, they could have easily made their own certificates that would be limited in use to their own PCs only. So why ask for a certificate that can spoof any website and will be trusted by every PC?
Simple Answer: Because corporations want it.
Blue Coat is a company that sells network security products. Many companies use their products for proxy services, etc. Most security products have problems scanning content that is encrypted using SSL. Having the ability to act as a MIM allows the proxy services, WAN acceleration boxes, etc. access to the content for processing. Companies today are hyper-concerned about losing Intellectual Property and with ensuring that employees are not doing anything at work that is considered inappropriate.
I find the use of the terms "surveillance" and "controversial" in the article title to be deliberately used as click bait. Blue Coat is no more a "surveillance" company than Cisco, Juniper, or F5. That their products have found their way into Iran and Sudan is not that surprising. I'm willing to bet that it wouldn't be that difficult to set up multi-deep shell companies to buy products.
Is it just me, or does it seem awfully odd that we have targeted recipients of these types of certs, while seemingly ignoring the issuer, assuming they would never be involved in misuse or abuse of certs?
In other words, who's watching the watchers? Do Symantec employees go through an extensive background investigation (to include financials to prevent coercion), polygraph testing, and subjected to massive audits? If not, given the power they wield, why?
The whole concept of a certificate authority is broken, by design.
Use self-signed certs.
Users must accept a cert on first use.
Users must be presented with a dialog if it ever changes, showing the new cert's info, thumbprint, etc., with options to accept/reject.
Individual certs can specify revocation lists if they want. Upon revocation, users should be presented with a dialog, as with a change to a cert.
Ideally, all of this would be bidirectional. Servers and clients authenticating each other. Yes, I would expect to have to walk into a physical business to establish this securely, offline. Exchange certs in meat space and then use them in cyber space. Unique certs for every client/server pair. Storage is cheap. Management is easy. Lost your cert? Reestablish in meat space. Less convenient, more secure.
Except if you're scanning your company machines, you can do exactly what the OP said Blue Coat should have done. Issue your own cert, and make all your workstations trust it.
The article uses dumbed-down speech for normals in a way that's confusing to us. For Slashdot crowd, it'd be better to say "wildcard intermediate CA" outright -- most readers will understand, the rest can blargh the meaning from context and comments.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
The linked article in the OP is a little vague, but based on my knowledge of the way that Symantec's certificate business is configured, I suspect it might actually be an Intermediate Certificate.
Basically the way this works is that Symantec have one single "Master" certificate, aka the "Root Certificate" for the CA. However, instead of using this one single digital key to sign all the certificates that all of Symantec's clients request, they actually use a series of "Intermediate Certificates". Think of this like a directory hierarchy with a root folder, some Top Level Directories, then a bunch of directories below that. Same deal.
This structure allows Symantec to grant the right to sign certificates based on logical groups or clusters; it also allows them to "bulk disallow" everything signed by the intermediate certificate by revoking that one file. Obviously, as the OP pointed out, an Intermediate is still allowed to "sign" certificates, with those produced having the full authority of being produced by Symantec.
What this would allow BlueCoat to do would be to sign any number of certificates as if they were signed by Symantec themselves. Bearing in mind, as others have pointed out, that BlueCoat sell filtering proxy servers and SSL interceptors, what this would allow them to do would be to effectively run "official" MitM (Man in the Middle) interceptions, in a pretty-much indetectable way, against any web site that uses Symantec Certificates.
There's quite rightly a fair bit of alarm in many posts here, suggesting that this would allow BlueCoat to spy on end users. However, the most likely scenario is that BlueCoat are using the certificates to upgrade the capabilities of their corporate proxy/filter/accelerator products for their large corporate clients. Big companies have a major issue with the leakage of proprietary information being sent off-network under the guise of SSL traffic; there are all sorts of malware packages that use SSL to communicate with their CNC hosts... In other words, there are many companies that want to have the ability to monitor even the SSL-protected traffic generated by their employees when those individuals access the web. I love a good conspiracy theory as much as the next tekkie, but in this case I suspect the actual implementation is only really of interest to you if you work for a large corporate and they haven't actually *told* you that they are doing this.
However, as other posters have pointed out, this isn't the whole story; this technology can be placed elsewhere in the network, for example within an ISP infrastructure, so it can equally easily be used to monitor private individuals.
So, if you don't want your colleagues in SecOps [at work] to know what you've got in your bank account, don't log into your online banking from work...
I'm not entirely sure of this, but because this specific story relates to Symantec certificates [i.e. the old Verisign business] I don't think the impact would be quite so relevant if you use certs from elsewhere. For maximum security, of course, I guess you could simply download OpenCA, build an air-gapped machine, install and run the OpenCA on something not connected to any other network, and get your signed certificates to the outside world by installing a CD-R burner on your CA hardware and then cutting a CD or DVD each time you create a certificate. Yes, you could use a USB key if you really wanted to, but since we all know how easy it is to infect a thumb drive, that doesn't make any sense.
Why the fuck has this site descended into rampant tinfoil hat paranoia?
Because in the past 5 years the tinfoil hat paranoia was shown to be anything but.
This is the new norm. Assume the worst and you're most likely right.
From the article:
What does this mean? Could it be that they only can issue certificates for "*.bluecoat.com"?
If so, what is the problem?
There is no substitute for common sense. Especially, no body of rules will do.
Except if you're scanning your company machines, you can do exactly what the OP said Blue Coat should have done. Issue your own cert, and make all your workstations trust it.
Except that wouldn't work with BYOD, thus the need for a certificate like this so that everything Just Works.
Exactly. Rolling your own certs sounds good until you get into the logistics and the complexity of implementing it on an Enterprise scale. Most Enterprises come to the same conclusion and pay for corporate root certificates from Symantec, etc. for their internal PKI infrastructure. It turns out that it's cheaper than the cost of support to handle all of the one-off situations that rolling your own causes. Everything just works.
If one Android phone "BYOD" saw a certificate, any certificate, signed by this Intermediate, it would get flagged and probably show up in Google's CT logs.
That's the thing about BYOD. As well as not installing your bullshit fake roots, the devices some employee brings in to work aren't running your "no tale-telling" hack to shut up all the warnings and diagnostics when bad things happen so you can pretend it's secure.
And what do you know, NOTHING in the CT logs. Why? Well I guess it could be the that the Lizard people who did 9-11 also kidnapped Google's CEO and made him delete the evidence. Or, more likely, Blue Coat never used this as a MITM proxy CA because Symantec knows that sort of shit would ruin them.
The CA cert is pathlen:0 so it can't be used to sign more CA certs, the key itself would have be extracted and used to sign anything outside of Symantec's visibility.
I'm sure a lot of individuals who peruse this site every day are in a position to recommend and recommend AGAINST vendors. If enough of us at the Fortune X companies blackballed Bluecoat/Symantec/others of that ilk, one would think that would make a difference. After all, NOT buying that $20-50M satchell of poo in favor of another vendor with more transparency times 100's of the largest corporations might make a difference.\
Frankly, if I said "no Bluecoat" tomorrow, I doubt it would even be questioned. Do the needful. :)
Best,
Well, if you want to secure mobile devices you go with a mobile device management solution which would put your corporate cert on their phone and force it to use the proxy. It'd also help protect them when they're not on the corporate WiFi.
Such a copout answer. When it is your network, you deserve to control it.
They can not do ANYTHING except convince your browser that the connection to that domain is secire, and there are TONS of them already issued. Yet the article makes it sound like it breaks something.
The whole article is horrible in every single way and is designed to scaremonger.
Do not look at laser with remaining good eye.
"Blue Coat assures that it is not going to utilize the certificates to snoop on us." Right and registration of firearms won't lead to confiscation...except in NYC where it did.
This is completely wrong. I work for a very large corporation which uses Blue Coat proxies, and they absolutely do not have trusted root certificates they can just use (amongst other things, this would lead to Symantec's cross-signing being revoked).
They do the thing any IT department can do, which is everyone either runs a pre-built image with the proxy certificates baked in, or people (like me) who get dev machines end up dropping them in to suppress the "invalid cert" warnings.
> What about devices that won't let you add a new cert?
Those devices belong in their own firewalled-off VLAN, off your local network.
Even if you do MITM the SSL connection to a IoT device, what makes you think its cleartext underneath? Instead, there may well be another layer of Base64-encoded PKI message-exchange going on between the rogue IoT device and an external CnC server. The 'cleartext' won't trigger alerts because it does not match credit-card patterns or other detection patterns set in the infosec appliance.
You are assuming that its about blacklisting known bad patterns. For devices like that, the opposite is true - its about whitelisting known good patterns.
I'm waiting for a bank to sue the utter shit out of a company that has deployed one of these "enterprise network MiTM" devices after someone with access to it rips off bank accounts. They are an accident waiting to happen.
That's still only getting consent from one party. There's a huge pile of laws broken for sniffing encrypted traffic when the second party does not agree. Of course you they can be rung up and asked - "Hello, Bank of America, do you mind if we sniff all the passwords of your customers at this workplace?"
So as you say it's a mess.
There are a number of proposals out there that would allow you to distribute public keys for web sites in a way that removes the reliance on CAs for security.
Storing things in DNS and securing that with DNSSEC being one. The EFF has a proposal out there (cant remember what it's called) for this as well.
And there is a proposal that replaced CAs with a system where the certificate can be signed by multiple entities and then the client decides whether to trust the certificate based on whether it trusts the entities that have signed the certificate.
Why is it that the browser vendors and others haven't shown any interest in these alternatives to the CA system? Pressure from the CAs not to shut down their revenue? Are these alternative ideas not as good (or as secure) as their proponents claim?
"I wonder if some of the issue with self-signed certificates is due to somebody at some point deciding that the CA model was better than the federated, partial trust model of PGP keys and that makes it conceptually difficult to use x.509 certificates in the same way that PGP keys are used."
Either that or the companies running commercial CAs put a lot of effort into that meme... There is a *lot* of money in Certificate Authorities... Mark Shuttleworth sold his CA business to Verisign back in the day for $750 Million... If you think about it in those terms, peer-to-peer trust models such a PGP and GPG would always undercut commercial solutions.
What's really interesting, however, is to see how the certificate market has evolved. We still rely on a relatively small number of Commercial CAs, who in turn make a lot of money. But look at what we've done with DNS [massively federated], Email SPF (Sender Policy Framework) [massively federated] and you realise that the CA model is actually the odd one out.
It actually wouldn't be that difficult for us to set up a mechanism in which institutions could set up and host their own publicly-facing, self-signed certificates, with a simple on-line checking mechanism that would allow us to decide whether or not to trust that CA as part of our train-of-trust process. In fact, if we linked that with a version of OCSP it might even make things much stronger...
"Why is it easier to work with signatures than encryption?"
Here's a wild guess... If I prepare a file to send to you that I then decide I want to sign, I will typically send you a combined payload that consists of the original file, a signed digest of the file [SHA2 hash] and then my public certificate that contains the asymmetric portion of my signing key... In other words, I would, by convention, send you everything that you need to know in order to validate my signed message [working on the loose assumption that you have the root cert for my CA cached locally]. It's a neat, packaged payload that requires no negotiation and which contains some pretty tightly-specified files...
I think what we're describing for encryption [OK, specifically S/MIME] is an example of a loosely-specified definition which, through permitting flexibility in the model, has allowed so much "movement" that the flexibility has brought incompatibility with it. But, that's a wild guess...