6 ms·

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

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

ehsankia 10y ago
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.
- deleted 10y ago
  [deleted]
- nikanj 10y ago
  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.
234dd57d2c8dba 10y ago
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.
- theamk 10y ago
  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.
- jarym 10y ago
  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.
  - icebraining 10y ago
    TLS 1.3 is still quite new, doesn't seem outrageous that they take a bit to implement it.
    - deathanatos 10y ago
      This is a failure to implement any version of TLS correctly, not just v1.3. (TLS has support for version negotiation including receiving a hello from a client with a future version, such as v1.3.)
userbinator 10y ago
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.
- coderobe 10y ago
  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).
- ademarre 10y ago
  > 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 https://news.ycombinator.com/item?id=12655180
- tbrowbdidnso 10y ago
  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 end supports a newer version. It should say "oh we both support 1.2 let's use that" And apparently it's done this before so there's even less an excuse for it.
  - rocqua 10y ago
    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.
jlgaddis 10y ago
On the other hand, allowing stuff that you don't understand gives us things like the CSRF vulnerabilities in MongoDB and such. In the case of a security appliance -- such as this -- it should, in my opinion, "fail closed".
- deathanatos 10y ago
  Sorry, no. TLS is explicitly designed to allow smooth upgrading like this. This proxy is supposed to (in response to a client hello w/ TLSv1.3) respond with TLSv1.2 if that's what it supports. This is still a rigorous parsing of the input being given: nothing is "not understood": version negotiation is an inherent part of the protocol and is supposed to allow for painless upgrades to more secure protocols. The RFC (which if you're implementing TLS, you should have open at all times) explicitly calls out exactly this behavior: > Note: some server implementations are known to implement version negotiation incorrectly. For example, there are buggy TLS 1.0 servers that simply close the connection when the client offers a version newer than TLS 1.0. The quality of this vendor's implementation is extremely suspect.
  - rocqua 10y ago
    The issue only occurs in non-mitm mode, probably meaning the box doesn't actually do the TLS handsake, instead merely inspecting it.
skywhopper 10y ago
It's in BlueCoat's political interests to make sure TLS 1.3 rolls out as slowly as possible since it actively works against their entire business model, so they have zero incentive to be proactive about this until the TLS 1.3 extensions are approved that make MITM possible again.

ehsankia 10y ago

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.

deleted 10y ago
[deleted]
nikanj 10y ago
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.

234dd57d2c8dba 10y ago

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.

theamk 10y ago
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.
jarym 10y ago
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.
- icebraining 10y ago
  TLS 1.3 is still quite new, doesn't seem outrageous that they take a bit to implement it.
  - deathanatos 10y ago
    This is a failure to implement any version of TLS correctly, not just v1.3. (TLS has support for version negotiation including receiving a hello from a client with a future version, such as v1.3.)

userbinator 10y ago

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.

coderobe 10y ago
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).
ademarre 10y ago
> 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 https://news.ycombinator.com/item?id=12655180
tbrowbdidnso 10y ago
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 end supports a newer version. It should say "oh we both support 1.2 let's use that" And apparently it's done this before so there's even less an excuse for it.
- rocqua 10y ago
  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.

jlgaddis 10y ago

On the other hand, allowing stuff that you don't understand gives us things like the CSRF vulnerabilities in MongoDB and such. In the case of a security appliance -- such as this -- it should, in my opinion, "fail closed".

deathanatos 10y ago
Sorry, no. TLS is explicitly designed to allow smooth upgrading like this. This proxy is supposed to (in response to a client hello w/ TLSv1.3) respond with TLSv1.2 if that's what it supports. This is still a rigorous parsing of the input being given: nothing is "not understood": version negotiation is an inherent part of the protocol and is supposed to allow for painless upgrades to more secure protocols. The RFC (which if you're implementing TLS, you should have open at all times) explicitly calls out exactly this behavior: > Note: some server implementations are known to implement version negotiation incorrectly. For example, there are buggy TLS 1.0 servers that simply close the connection when the client offers a version newer than TLS 1.0. The quality of this vendor's implementation is extremely suspect.
- rocqua 10y ago
  The issue only occurs in non-mitm mode, probably meaning the box doesn't actually do the TLS handsake, instead merely inspecting it.

skywhopper 10y ago

It's in BlueCoat's political interests to make sure TLS 1.3 rolls out as slowly as possible since it actively works against their entire business model, so they have zero incentive to be proactive about this until the TLS 1.3 extensions are approved that make MITM possible again.