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

41–50 of 216 posts

Re: BlueCoat and other proxies hang up during TLS 1.3

#41

Post by theluketaylor »

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?

Pretty much all the endpoint solutions MITM exactly the same way as the middle box by running as a proxy listening on localhost. They also pretty much universally do an even worse job than the network middleboxes on handling invalid certs and supporting modern tls, hard as that may be to believe. Then you have the added nightmare of ensuring a client on tens or hundreds of thousands of enpoints is fully patched and functioning correctly.

Most of the solutions I have seen for devices outside the corporate perimeter are some combination of enforced vpn and authenticated proxy that is internet accessible.

Re: BlueCoat and other proxies hang up during TLS 1.3

#42

Post by schoen »

bgc wrote: post #30
x1798DE wrote: post #25

Earlier quoted context omitted.

They should lobby the school board not to do this nonsense.

The Board doesn't have a choice, under CIPA[0], content filtering is a requirement for the FCC's E-Rate program[1] in which the government pays some of the cost of the school's internet connection. [0] https://www.fcc.gov/consumers/guides/childrens-internet-prot... [1] https://www.fcc.gov/general/universal-service-program-school...

Could they try to find an alternative source of funds (as the San Francisco Public Library did), or adopt an interpretation of CIPA under which they don't have to use this particular feature?

Re: BlueCoat and other proxies hang up during TLS 1.3

#43

Post by prdonahue »

xfs wrote: post #40

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

Sure, it's a working draft, but companies are actively working to develop and test their server side integrations. Having to disable it like this harms those efforts as fewer users are making connections (by default).

Re: BlueCoat and other proxies hang up during TLS 1.3

#44

Post by HappyTypist »

theluketaylor wrote: post #37
ckuehl wrote: post #32

Earlier quoted context omitted.

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 emai…

Perfectly sensible and reasonable. Difficult to have any objections.

Re: BlueCoat and other proxies hang up during TLS 1.3

#45

Post by theamk »

234dd57d2c8dba wrote: post #27
coderobe wrote: post #3

Earlier quoted context omitted.

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

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.

But the traffic is totally understandable -- the right action does not require knowing what TLS 1.3 is.

The way it is supposed to work is as following: there is a protocol negotiation when the connection is established (which is obviously unencrypted), which contains TLS version supported. If MITM proxy does not understand the version, it can just change these bytes to force hosts to negotiate at a lower version.

So the only reason BlueCoat fails is because the authors failed to implement force version downgrade.

Re: BlueCoat and other proxies hang up during TLS 1.3

#46

Post by coderobe »

userbinator wrote: post #39
coderobe wrote: post #3

Earlier quoted context omitted.

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…

Client and Server exchange a list of capabilities at the beginning of a TLS connection, if the proxy just filters out the protocols/versions it doesn't understand, server/client will agree on a different version (like 1.2).

Re: BlueCoat and other proxies hang up during TLS 1.3

#47

Post by [deleted] »

bgc wrote: post #30
x1798DE wrote: post #25

Earlier quoted context omitted.

They should lobby the school board not to do this nonsense.

The Board doesn't have a choice, under CIPA[0], content filtering is a requirement for the FCC's E-Rate program[1] in which the government pays some of the cost of the school's internet connection. [0] https://www.fcc.gov/consumers/guides/childrens-internet-prot... [1] https://www.fcc.gov/general/universal-service-program-school...

[deleted]

Re: BlueCoat and other proxies hang up during TLS 1.3

#48

Post by fulafel »

bgc wrote: post #30
x1798DE wrote: post #25

Earlier quoted context omitted.

They should lobby the school board not to do this nonsense.

The Board doesn't have a choice, under CIPA[0], content filtering is a requirement for the FCC's E-Rate program[1] in which the government pays some of the cost of the school's internet connection. [0] https://www.fcc.gov/consumers/guides/childrens-internet-prot... [1] https://www.fcc.gov/general/universal-service-program-school...

Of course they have a choice. It's not very princinpled to sell your children's online privacy in exchange for some "grant" money going to an oppressive-dictatorship supporting company like BlueCoat.

(Also it's possible can do server address based blocking without MITM)

Re: BlueCoat and other proxies hang up during TLS 1.3

#49

Post by ademarre »

userbinator wrote: post #39
coderobe wrote: post #3

Earlier quoted context omitted.

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…

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

This reminds me of firewalls that weaken security by filtering unrecognized HTTP headers: https://news.ycombinator.com/item?id=12655180

Re: BlueCoat and other proxies hang up during TLS 1.3

#50

Post by ec109685 »

discreditable wrote: post #21
Viper007Bond wrote: post #11

Earlier quoted context omitted.

Isn't MITM required in enterprise environments where they want to filter content? Unless you want to run it client-side which isn't usually an option.

Basic filtering can be done via passively inspecting SNI headers and terminating connections to verboten hosts. However, that's not enough for some orgs, and some software works around it: https://www.bamsoftware.com/papers/fronting/

Even simple tls handshake filtering is broken with BlueCoat's implementation.
Post reply on HN