Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

BlueCoat and other proxies hang up during TLS 1.3

bugs.chromium.org

Post reply on HN
Print view View original

31–40 of 216 posts

Re: BlueCoat and other proxies hang up during TLS 1.3

#31

Post by throwaway2048 »

discreditable wrote: post #18
jessaustin wrote: post #9

I guess in future, TLS upgrades will be opt-in?

This is something the TLS spec authors have prepared against with GREASE. The idea is the client adds some junk version information to its list of supported protocols. To quote: "Correct server implementations will ignore these values and interoperate. Servers that do not tolerate unknown values will fail to interoperate with existing clients, revealing the mistake before it is widespread." https://tools.ietf.org/htm…

This dosent really seem to solve anything, everyone now ignores the enumerated GREASE values as they are reserved upfront, and will continue to cause failures with other extended values. yay?

Re: BlueCoat and other proxies hang up during TLS 1.3

#32

Post by ckuehl »

wildmusings wrote: post #22
db48x wrote: post #10

The long-term solution is simply not to work anywhere that insists on running a MITM attack on all of your communications.

Without an SSL MITM, Intrusion Detection Systems (IDS's) are much less effective. 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 t…

Totally agreed they have the right to monitor your network traffic, but I still think in most cases employees should try to push back on this.

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.

Re: BlueCoat and other proxies hang up during TLS 1.3

#33

Post by userbinator »

db48x wrote: post #10

The long-term solution is simply not to work anywhere that insists on running a MITM attack on all of your communications.

I MITM my own connections for filtering purposes. It turns out to be the most effective way of blocking and changing crap in not just my main browser (of which I use several), but those embedded in other apps, for phoning home or otherwise.

Re: BlueCoat and other proxies hang up during TLS 1.3

#34

Post by adrr »

wildmusings wrote: post #22
db48x wrote: post #10

The long-term solution is simply not to work anywhere that insists on running a MITM attack on all of your communications.

Without an SSL MITM, Intrusion Detection Systems (IDS's) are much less effective. 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 t…

Put it on the endpoint. You already need protection on the endpoint to protect against malware, etc and MITM solutions only cover assets on the internal network. What about company laptops?

Re: BlueCoat and other proxies hang up during TLS 1.3

#35

Post by rblatz »

wildmusings wrote: post #22
db48x wrote: post #10

The long-term solution is simply not to work anywhere that insists on running a MITM attack on all of your communications.

Without an SSL MITM, Intrusion Detection Systems (IDS's) are much less effective. 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 t…

With SSL MITM, Intrusion Detection Systems aren't even effective.

Re: BlueCoat and other proxies hang up during TLS 1.3

#36

Post by rossy »

mrmondo wrote: post #6
JoshTriplett wrote: post #2

Note that this happens even when using a BlueCoat proxy in non-MITM mode. BlueCoat tries to "analyze" TLS connections, and rejects anything it doesn't understand. This exact issue occurred with TLS 1.2 back when BlueCoat only understood 1.1/1.0. 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 tr…

BlueCoat are an incredibly evil company that are breaking the internet.

BlueCoat makes me cry. We have an application running inside the firewall of one of our clients that communicates with a HTTPS REST API hosted by a server in our datacenter. The connection must be encrypted because it handles confidential information, but when it passes through BlueCoat's TLS proxy, the Authorization header gets mangled and it can't authenticate against our backend. Higher-ups decided that it would be better to try to convince the client to let our app bypass their proxy than to implement a custom workaround for BlueCoat users, but the client never let us through, so the only solution we could implement involved manually SCPing the required data between client and server.

Re: BlueCoat and other proxies hang up during TLS 1.3

#37

Post by theluketaylor »

ckuehl wrote: post #32
wildmusings wrote: post #22

Earlier quoted context omitted.

Without an SSL MITM, Intrusion Detection Systems (IDS's) are much less effective. 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 t…

Totally agreed they have the right to monitor your network traffic, but I still think in most cases employees should try to push back on this. 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 recen…

At my workplace where we have to do tls inspection for regulatory purposes we provide an internet-only wifi network for employee personal use where we don't intercept TLS. This network is fully isolated from the corporate network and corporate devices join a different, more monitored network. I believe this strikes the best balance between regulatory compliance and employee privacy. People can still use personal email or do online banking while at the office without inspection, but no corporate data can be moved en mass off company servers.

Re: BlueCoat and other proxies hang up during TLS 1.3

#38

Post by detaro »

adrr wrote: post #34
wildmusings wrote: post #22

Earlier quoted context omitted.

Without an SSL MITM, Intrusion Detection Systems (IDS's) are much less effective. 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 t…

Put it on the endpoint. You already need protection on the endpoint to protect against malware, etc and MITM solutions only cover assets on the internal network. What about company laptops?

Endpoint-based MITM solutions tend to be even worse for security, since they have a larger attack surface (and generally seem to be really badly implemented). On the plus side, some things can be done locally without MITM.

From a privacy perspective, it doesn't really matter if the monitoring happens centralized or not.

In the cases where I've seen strict filtering laptops were forced through VPN connections to HQ, where the gateway then decides what parts of internal and external networks they are allowed to access.

Re: BlueCoat and other proxies hang up during TLS 1.3

#39

Post by userbinator »

coderobe wrote: post #3
JoshTriplett wrote: post #2

Note that this happens even when using a BlueCoat proxy in non-MITM mode. BlueCoat tries to "analyze" TLS connections, and rejects anything it doesn't understand. This exact issue occurred with TLS 1.2 back when BlueCoat only understood 1.1/1.0. 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 tr…

Rejecting anything it doesn't understand sounds like a bug to me. If it sees that it's TLS, it should attempt a protocol downgrade. There's absolutely no reason for this to break, as TLS 1.3 exists alongside TLS 1.2 (For now).

Rejecting anything it doesn't understand sounds like a bug to me.

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.

Re: BlueCoat and other proxies hang up during TLS 1.3

#40

Post by xfs »

The title was editorialized. TLS 1.3 is a working draft and Chromium is just doing field trial with it.

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

Post reply on HN