BlueCoat and other proxies hang up during TLS 1.3

Post by nl » Tue, Feb 28, 2017, 4:48 AM UTC

jessaustin wrote: post #8

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…

This exact issue occurred with TLS 1.2 back when BlueCoat only understood 1.1/1.0. 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 ser…

Post by dvorak42 » Tue, Feb 28, 2017, 4:57 AM UTC

throwaway2048 wrote: post #31

discreditable wrote: post #18

Earlier quoted context omitted.

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?

Post by nl » Tue, Feb 28, 2017, 5:03 AM UTC

komali2 wrote: post #57

Who's the guy with fifty thousand Chromebooks? Goodness.

Post by theluketaylor » Tue, Feb 28, 2017, 5:23 AM UTC

zrm wrote: post #54

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…

> If you're using your company's network, then they have every right to monitor all of the activity on it. 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…

Post by btbuilder » Tue, Feb 28, 2017, 5:44 AM UTC

riffic wrote: post #59

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…

If you're using your company's network, then they have every right to monitor all of the activity on it. This is tantamount to steaming open and resealing the envelopes of all physical mail. Have some god damn ethics, I'd sooner quit than snoop traffic in this manner.