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

101–110 of 216 posts

Re: BlueCoat and other proxies hang up during TLS 1.3

#101

Post by dagss »

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.

If the use of the MITM is public it is more like requiring you to leave outbound paper mail in an outbox without an envelope, then have the internal mail office archive it and add the envelope. Perfectly reasonable.

What you do while on work should not be personal and thus cannot be snooped upon.

If you need to send a personal paper letter, you would go to the post office, not send it using the company's stamps, right?

Re: BlueCoat and other proxies hang up during TLS 1.3

#102

Post by zrm »

jlgaddis wrote: post #86
zrm wrote: post #72

Earlier quoted context omitted.

> We opted to disable usb mass storage since cavity searches seemed a little much This is missing the point. Someone could plug a SATA drive directly into the motherboard, or otherwise compromise their work computer to disable the restrictions, or take pictures of documents with a camera, or bring their own computer on-site, or bring a line-of-sight wireless network device on-site, or send the data over the internet…

And the A-Team could land on the roof with a helicopter in the middle of the night, take control of the building, breach the data center, and physically steal and leave with all the servers. Yes, if one is determined enough, they will find a way to steal data. > It isn't worth the security cost. That's up for the company to decide... and apparently they have decided that it is worth the cost, regardless of what zrm ,…

That is just an appeal to authority rooted in the assumption that corporations never make purchasing decisions based on vendor marketing.

Re: BlueCoat and other proxies hang up during TLS 1.3

#103

Post by adrianN »

semi-extrinsic wrote: post #85
jessaustin wrote: post #8

Earlier quoted context omitted.

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…

There was a paper posted on HN a few weeks back by some pretty serious security researchers on the security risks of SSL MITM boxes. 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 floo…

It might backfire and your company forbids HTTPS "so that employees can't disclose company secrets without IT having traceability".

Re: BlueCoat and other proxies hang up during TLS 1.3

#104

Post by ploxiln »

jessaustin wrote: post #9

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

To explain the other answer a bit more: TLS upgrades have always been opt-in. The problem is that you have to be very clever where you put that option, or some (expensive and popular and dumb) webservers and middleboxes will just freak out and block the client.

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

Re: BlueCoat and other proxies hang up during TLS 1.3

#105

Post by cm2187 »

semi-extrinsic wrote: post #85
jessaustin wrote: post #8

Earlier quoted context omitted.

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…

There was a paper posted on HN a few weeks back by some pretty serious security researchers on the security risks of SSL MITM boxes. 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 floo…

Yeah. This is a firable offense. The solution to your company MITM your traffic is not to use your work computer for anything personal that matters. It's not like if we had a shortage of devices to connect to the internet.

Re: BlueCoat and other proxies hang up during TLS 1.3

#106

Post by ptaipale »

adrianN wrote: post #103
semi-extrinsic wrote: post #85

Earlier quoted context omitted.

There was a paper posted on HN a few weeks back by some pretty serious security researchers on the security risks of SSL MITM boxes. 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 floo…

It might backfire and your company forbids HTTPS "so that employees can't disclose company secrets without IT having traceability".

They can't, really. So much of the Web has fortunately moved to HTTPS that then they should just forget about Web access.

Re: BlueCoat and other proxies hang up during TLS 1.3

#108

Post by jarym »

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.

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.

Re: BlueCoat and other proxies hang up during TLS 1.3

#109

Post by trome »

adrianN wrote: post #103
semi-extrinsic wrote: post #85

Earlier quoted context omitted.

There was a paper posted on HN a few weeks back by some pretty serious security researchers on the security risks of SSL MITM boxes. 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 floo…

It might backfire and your company forbids HTTPS "so that employees can't disclose company secrets without IT having traceability".

Uhh, what do you do for sites that don't offer HTTP? Many sites force a 301 redirect when hit on HTTP, and won't downgrade.

Re: BlueCoat and other proxies hang up during TLS 1.3

#110

Post by rocqua »

tbrowbdidnso wrote: post #55
userbinator wrote: post #39

Earlier quoted context omitted.

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…

The TLS negotiation is mutual. Both endpoints tell each other what they support and they agree on a protocol that's mutually supported. If merely advertising 1.3 while still advertising older versions causes blue coat to break, it has a bug in TLS version negotiation. There is no downgrade or whitelist or failing closed. Each end says what they support and BlueCoat blows up the connection if it sees that the other en…

This is apparently a problem when bluecoat is used in non-mitm mode. That probably means bluecoat is merely inspecting the initial handshake, not modifying it. That would imply it can't actually modify the handshake.

It then simply inspects a connection it doesn't understand and 'fails closed' by preventing that connection.

Post reply on HN