Live data from Hacker News

BlueCoat and other proxies hang up during TLS 1.3

bugs.chromium.org

131–140 of 216 posts

Re: BlueCoat and other proxies hang up during TLS 1.3

#131
post #52

Earlier quoted context omitted.

I think this SSL MITM thing has gone way too far. When an exec asks an engineer if it's possible to monitor all internet communication that goes in and out of the company network, including communication that is encrypted by TLS, the correct answer is no. In fact, this specific thing is what TLS is designed to prevent, and new implementations of the protocol are only going to get better at preventing it. The exec wil…

> still doesn't protect you against (...) malware written by people who have SSL MITM proxies in mind Exactly this is what I don't get. Since these abominations are becoming ubiquitous, surely malware writers are starting to work on workarounds? And in this case, it's as easy as setting up an SSH tunnel and running your malware traffic through that, which is a few days of work at best for a massive ROI?

Not even malware writers: on the recent Cloudflare incident, there was one password manager which was affected, but the leak was harmless for them because the content within their TLS connections had another layer of encryption. Both MITM proxies and their TLS-terminating CDN can see only encrypted data.

Re: BlueCoat and other proxies hang up during TLS 1.3

#132

Earlier quoted context omitted.

It sounds like it might be a worthwhile effort to reverse engineer one of those.

Reverse-engineer? A middlebox? Which holds trusted secret keys and which, in its normal unremarkable operation, intercepts, parses , reconstructs, decrypts, re-encrypts, forwards, and optionally logs both confidential and attacker-controlled traffic? And is also known to be used for nationwide bulk internet censorship by regimes often called 'oppressive'? Why, doesn't it just. Please consider, very carefully, the eth…

What's true is true - better to know it than stick our heads in the sand. If these boxes have vulnerabilities (who am I kidding, they do parsing, they're probably implemented in C "for performance", of course they have vulnerabilities), we are better off for knowing about them than not.

Re: BlueCoat and other proxies hang up during TLS 1.3

#133
From https://www.bluecoat.com/products-and-solutions/ssl-visibili...

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

Re: BlueCoat and other proxies hang up during TLS 1.3

#134
post #112

Earlier quoted context omitted.

Is both SSH and USB key / USB DVD burner usage completely disabled on your corporate devices? If not, obvious workaround is obvious.

Even a full mitm solution doesn't MitM the sneakernet.

Ah yes, but a literal MitM solution could!

Re: BlueCoat and other proxies hang up during TLS 1.3

#135
post #107

Edit: oops, my mistake. Carry on. > 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.

This was not intended to be read as a personal attack, sorry about that.

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.

Re: BlueCoat and other proxies hang up during TLS 1.3

#136
post #108

Earlier quoted context omitted.

It's a security feature, often malware will send encrypted traffic over 443 in an attempt to bypass firewalls. If BlueCoat can't understand the traffic, it drops it as it assumes it's malicious.

The Bluecoat sales people did a number on you huh? Sounds really good until you ask 'why doesn't Bluecoat understand this traffic' - because it really should.

TLS 1.3 is still quite new, doesn't seem outrageous that they take a bit to implement it.

Re: BlueCoat and other proxies hang up during TLS 1.3

#137
This is even crazier than people may think on the first look.

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.

Re: BlueCoat and other proxies hang up during TLS 1.3

#138
Blue Coat makes MitM/censoring devices, probably every wannabe shithole* with a dictator has it or competitors product installed.

https://citizenlab.org/2013/01/planet-blue-coat-mapping-glob...

*Egypt, Kuwait, Qatar, Saudi Arabia, the UAE. Afghanistan, Bahrain, China, India, Indonesia, Iraq, Kenya, Kuwait, Lebanon, Malaysia, Nigeria, Qatar, Russia, Saudi Arabia, South Korea, Singapore, Thailand, Turkey, and Venezuela.

Re: BlueCoat and other proxies hang up during TLS 1.3

#139
post #13

Wouldn't it be better to allow enterprises to do version pinning (which I believe used to be supported in chrome enterprise), rather than remove TLS 1.3 for everyone?

You mean giving control back to the users of your software? Google doesnt play like that. Motership knows best!

You cant even freeze chrome extensions.

Re: BlueCoat and other proxies hang up during TLS 1.3

#140
post #121

It sounds like if you run a web server, you should think about only supporting TLS 1.3 with no downgrade support, to ensure security without the possibility of your visitors' being subject to interception by a third party (even if it is their own enterprise).

The second party in this instance is the organisation, including the user. The enterprise owns the pipe, the router, the endpoint device, the chair the user sits on, and the time being used by the employee while they are not on a break. They are a representative of the enterprise while they use a workplace computer, and while they do have an expectation of privacy on devices under certain circumstances, that is balanced with my need to protect the enterprise from bad actors. I am obliged to MitM the significant majority of SSL connections, but I do so after acquiring informed consent from the employee. This is via both workplace policy to which they must agree to remain employed, and via clickthrough notification on logon that SSL is intercepted and use is monitored. In exchange, I will only make use of information collected that is pertinent to such protection activities. For instance, if I see a Bookface post about a party at the weekend posted during a break, that is discarded. If a post is captured that is sending business-confidential information to a competitor, that is collected and used in a formal process.

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.

Post reply on HN