zlacker

>>codero+(OP)
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 trials and other configuration. Firefox had a similar issue, where they temporarily used more conservative settings for their updater than for the browser itself, to ensure that people could always obtain updates that might improve the situation.

>>JoshTr+w
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).

>>codero+31
The surprising part (or maybe not) is that BlueCoat had been made aware of this change months ago and never got around properly testing it. This one of the softwares main purpose, and the fact that they didn't even make sure it works on the newest Chrome, leading to such a mess, is pretty sad.

>>ehsank+n1
The way this is going to be spinned, I promise you, is: Google released a new version of Chrome, and support for that upgrade is in BlueCoat v.next. Here's an invoice for the new license+consulting services for the upgrade.

In corporate environments, the last thing that changes is the thing that gets blamed. BlueCoat was not upgraded, Chrome was, and now things are broken? Not their fault.