Which spec is this? As far as I know `http://google` is completely fine, and the period at the end is only necessary for the browser address bar heuristics we're talking about. `http://to` was operated as a URL shortener for a while.
So if there was a host on my network named 'ai', http://ai would resolve there (The terminating dot being standard to indicate a fqdn, rather than a browser trick). This has been understood for a long time; rfc1049 gives us:
Relative names are either taken relative to a well known origin, or to a
list of domains used as a search list. Relative names appear mostly at
the user interface, where their interpretation varies from implementation to implementation[.]
I stress that last clause; dotless domains have no defined behaviour. "http://google/" may refer to google.example.com. (relative to my search list), google.com. (relative to a well-known origin), or google. (a fqdn). That's not browsers, or omnibars, it's been the vagueness of undotted-domains since the start.
Possibly. But with two complications - one is that there is no defined correct behaviour for undotted domains. All the RFC gives us is "implementation vary". Second is that this behaviour is inherited from gethostbyname(), so it's unlikely to change soon.
Technically the root zone has to have NS records. So even records without a label at all should work. of course you can not resolve them without a static zone configuration.
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).
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.
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.
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.
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.
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.
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).
I've written a similar rebuttal to your sibling's comment here[1].
This isn't "failing closed", and this isn't a whitelist. TLS allows you to whitelist to certain versions of the protocol during the initial negotiation at the start of the protocol; that is the opportunity for either end to state what version of the protocol they'd like. It is not permissible in the protocol to close the connection as Blue Coat is doing.
This isn't a downgrade attack, either: both server and client are free to choose their protocol version at the beginning. The client & server will later verify that the actual protocol in use is the one they intended; this is what prevents downgrades.
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.
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.
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.
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.
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.)
That's exactly what coderobe said, that it will be rebranded and split off from the company. Just because it's called something else doesn't mean it's "dead".