If you're using your company's network, then they have every right to monitor all of the activity on it. They're trying to protect trade secrets, future plans, customer data, employee records, etc. from attackers who would use that information to do harm to the company, its customers, and its employees. If you don't want your employer to know what you're doing, then don't use the company computer or company network to do it. And while you may think that you're too tech savvy to fall prey to malware 1) not everyone at your company is, and 2) no amount of savvy will protect you from all malware, especially ones that gain a foothold through an unpatched exploit. And there's also that whole other can of worms: malicious employees.
Now, because engineers are so bad at saying 'no' to the people who want SSL MITM, it's apparently become a regulatory requirement. SSL MITM might let you passively surveil your employees' Facebook Messenger conversations, but it still doesn't protect you against a malicious employee who is tech-savvy (or malware written by people who have SSL MITM proxies in mind.) They could just put the information they want to smuggle out of the network into an encrypted .zip. They could even do something creative like using steganography to hide it in family photos that they upload to Facebook. The only real solution to this is to lock down the devices that people access the network on, not the network itself.
At least from my view, it's not so much that I don't want my company to know what I'm doing, as that I don't trust their software to securely MITM all of my traffic. This thread doesn't fill me with confidence about the competency of these corporate MITM proxies. And the recent Cloudflare news doesn't help either -- they're effectively the world's largest MITM proxy, and even they couldn't avoid leaking a huge amount of "secure" traffic.
There are surely sectors where it's necessary for a company to MITM all traffic, but I think most companies will do better security-wise by not messing with TLS. It's just too hard to get right.
It isn't a question of whether they're allowed to do it, it's a question of whether they should do it.
It's ineffective against insider exfiltration of data unless you're also doing body cavity searches for USB sticks, and if you're at that point then the sensitive network should not be connected to the internet at all.
And it's similarly ineffective against malware because TLS is not the only form of encryption. What difference does it make if someone uploads a file using opaque TLS vs. uploading an opaque encrypted file using MITM'd TLS? Banning encrypted files, even if you could actually detect them, doesn't work because they're often required for regulatory compliance.
It isn't worth the security cost. The situation in the article is bad enough, but consider what happens if the MITM appliance itself gets compromised when it has a root private key trusted by all your devices and modify access to all the traffic.
There's a good argument that it's unethical too. There are many ways where your company has to trust you instead of pervasively monitoring your doings and communications, and this should fall in the same area.
If you're using your company's network, then they have every right to monitor all of the activity on it.
I don't think so. Since when is it legal for anyone to circumvent encryption systems?
Is it legal for your ISP to do this on "their network"? Actually, I bet you think that's OK too.
Then don't filter content.
What these "enterprise environments" want is to leech off the Internet's knowledge while keeping a firm chokehold on the privacy of their own employees Sadly, it looks like Google is caving in to their pressure.
In this case, it doesn't sound like they're reverting it because of overall breakage, but rather because it breaks the tool that would otherwise be used to control TLS 1.3 trials and other configuration. Firefox had a similar issue, where they temporarily used more conservative settings for their updater than for the browser itself, to ensure that people could always obtain updates that might improve the situation.
Good grief! From David Benjamin's final comment:
Note these issues are always bugs in the middlebox products. TLS version negotiation is backwards compatible, so a correctly-implemented TLS-terminating proxy should not require changes to work in a TLS-1.3-capable ecosystem. It can simply speak TLS 1.2 at both client <-> proxy and proxy <-> server TLS connections. That these products broke is an indication of defects in their TLS implementations.
It's understandable that I've never heard of BlueCoat: clearly this product's success is based more on selling to executives than on quality, and it has been some time since I worked in an organization that had executives to sell to.
https://jhalderm.com/pub/papers/interception-ndss17.pdf
How do you fix this when you're naught but a humble employee? Well, a friend of mine worked at a fairly large tech company where a salesguy for these boxes had convinced the CTO they had to have them. Every tech-person "on the floor" hated the idea, so before the boxes were installed they conspired on their free time to write some scripts that ran lots of legitimate HTTPS traffic, effectively DDOSing the boxes and bringing the company's internet to a crawl for the day, like Google would take ten seconds to open. Then obviously everyone (including the non-tech people) started calling the IT helpdesk complaining that the internet was broken. MITM box salesguy then had to come up with a revised solution, costing 20x more than his first offer, and that was the end of that.
If you already are suffering under MITM boxes, a similar strategy with a slow ramp-up in traffic might work.
[1] https://en.wikipedia.org/wiki/Blue_Coat_Systems#Use_by_repre...
Quite a pain to work in such environments.
Even protocol state (equivalents of TCP FIN/SYN/etc) is encrypted, to ensure that middleboxes don't get ideas about what the protocol is 'supposed' to do - ideas which make it hard to change the protocol in the future.
There are hundreds of thousands of organizations that need inspection and caching and proxying of internal www traffic. That all protocols should disallow or frustrate this disregards real needs of users and organizations.
Further still, if protocols can't be designed to be implemented easily or to allow for implementation bugs or lack of features, it's a crap protocol or application. Middleware will always be necessary, and encryption really shouldn't change the requirements of how middleware needs to work with a protocol.
It sounds like a perfectly reasonable behaviour if the goal is to "fail closed", to provide more security in a fashion similar to a whitelist.
If it sees that it's TLS, it should attempt a protocol downgrade.
I don't remember the exact details but I recall reading that TLS has a mechanism to prevent version downgrades, precisely to defend against such "attacks", so the connection would not succeed in that case either.
In the case of a security appliance -- such as this -- it should, in my opinion, "fail closed".
While there was previously this "TLS fallback" implemented in Chrome to work around buggy endpoints, this was primarily due to buggy endpoints* which was a much larger issue and difficult to fix, while these middlebox issues affect a much smaller portion of users and we're hopeful that the middlebox vendors that have issues can fix their software in a more timely manner.
* TLS 1.3 moves the version negotiation into an extension, which means that old buggy servers will only ever know about TLS 1.2 and below for negotiation purposes and won't break in a new matter with TLS 1.3.
A few days ago there were other issues with this causing Chromium to stop working on *.google.com so it's not just about middle-boxes.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855434
https://bugs.chromium.org/p/chromium/issues/detail?id=693943
The obvious place is the TLS version number in the handshake. It can say "I support up to TLS 1.3" and the other side can say "I support up to TLS 1.2" and the obvious choice is 1.2. But again, some webservers and middleboxes, as soon as they see 1.3 there, they freak out, block the connection completely.
Another idea for where to put it is in the candidate ciphers list - a "oh and I support TLS 1.3" pseudo-"cipher". The other side is supposed to just not use it if it's not recognized. Bug again, some stuff out there just freaks out.
Why do they freak out? Sometimes it's because someone thought that any unrecognized bit could be a hacking attempt. Sometimes it's because the software starts as a pile of bugs and is just debugged to the point that it mostly works today (and at that time "1.3" was never seen at exactly that spot).
So the goal of "GREASE" is to put random not-enumerated values in places like the ciphers list. Once a server or middlebox is compatible with GREASE, it'll be compatible with any future optional upgrade signal being present in those parts of the TLS handshake.
(I'm not sure where GREASE has been implemented so far, and I'm not sure if TLS 1.3 is 100% finalized yet.)
I understand that proper network hosts will negotiate TLS versions rather than "freaking out".
They also have 46,000 PCs. So yeah - pretty decent size...
Why isn't there an effort to detect MITM proxies and post equally scary warnings? Surely users have a right to know.
MITM is worse than self signed certs and if 'exceptions' can be found for MITM like corporate security, management etc then the same exceptions should be found for self signed certs for individuals rather than creating dependencies on CA 'authorities'. This just another instance of furthering corporate interests while sacrificing individuals.
The scary warnings for self-signed certificates are in fact a protection against MITM. It's because of them that MITM proxies are forced to install a CA certificate. The main difference is that installing a CA certificate requires explicit action in the browser (and on some newer systems displays scary warnings), while if a MITM proxy could simply present a fake self-signed certificate, it could easily intercept anyone. Therefore, self-signed certificates are strictly worse.
You can create a self signed CA and add it to trusted roots to avoid warnings.
Why not promote content encryption or explore other ideas that do not rely on central authorities, and we can see there are always workaround for corporates but individuals are thrown under the bus.
If you break my ability to monitor the use of my devices, your product is dropped from my network. You'll also find that it is dropped from the entire education sector. That is why Chrome has backed off this change.
On Android every time a user-installed certificate authority is used a warning is shown. Furthermore, the user is forced to set a lock screen the moment you install a certificate.
If Google can push this (frankly user unfriendly) UI through, why not change "Secure" into "Monitored" in Google Chrome? The green padlock is a lie and the truth is exposed only after inspecting the certificate using the web developer tools.
> Have some god damn ethics
Personal attacks are not allowed on HN. We ban accounts that do this, so please don't do it.
We detached this subthread from https://news.ycombinator.com/item?id=13750650 and marked it off-topic.
My intention was a (perhaps poorly worded) call on those in the industry to have a sense of ethics, and not meant to single any person in particular.
> "Enterprise class Blue Coat’s SSL Visibility Appliance is comprehensive, extensible solution that assures high-security encryption. While other vendors only support a handful of cipher-standards, the SSL Visibility Appliance provides timely and complete standards support, with over 70 cipher suites and key exchanges offered, and growing. Furthermore, unlike competitive offerings, this solution does not “downgrade” cryptography levels and weaken your organization’s security posture, putting it at greater risk. As the SSL/TLS standards evolve, so will the management and enforcement capabilities of the SSL Visibility Appliance."
You cant even freeze chrome extensions.
> At this point it's worth recalling the Law of the Internet: blame attaches to the last thing that changed.
> There's a lesson in all this: have one joint and keep it well oiled.
> When we try to add a fourth (TLS 1.3) in the next year, we'll have to add back the workaround, no doubt. In summary, this extensibility mechanism hasn't worked well because it's rarely used and that lets bugs thrive.
The TLS community knew that there would be problems with the deployment of TLS 1.3 with version intolerance, because there always have been. That's why the version negotiation was changed and a mechanism called GREASE was invented to avoid just such problems. But it seems BlueCoat has shown us that there's no way to anticipate all the breakage introduced by stupid vendors.
The takeaway message is this: Avoid Bluecoat products at all costs. These companies are harming the Internet and its progress.
Also, wasn't there some security issues relating to the possibility to downgrade the encryption of a connection?
I think its reasonable for a company to want to filter everything that comes through their pipe, if anything, it's a bit of a liability not to do it, but at the same time, non-technical people should understand that their connection is being unencrypted and re-encrypted, and be educated on the consequences.
There are a few local coffee shops which terminate SSL, and when people see me closing my browser and laptop, or starting to tether through my phone because of the cert error they tell me "oh, you just need to accept all those certs!".