Hacker Newsnew | past | comments | ask | show | jobs | submit | more coderobe's commentslogin

It would probably work, but it would break spec.


It definitely works http://ai.

The period needs to be part of the URL at least for Chrome but HN isn't rendering it as part of the link.


In Chrome, the link (without the period) in your comment worked for me


It turns out it was my DNS settings. It was trying to lookup ai.company-name.com without the period.


Also http://dk.


the period has to be there because it breaks spec btw


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.


It's not just browsers. eg;

  $ host -v ai
  Trying "ai.home.example.com"
  Trying "ai"
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29228
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.


I see what you're saying but these all seem like client-side issues to me.


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.


There should be no A-labels on bare gTLDs, so "https://google" should never make sense (per SSAC053 report - https://www.icann.org/groups/ssac/documents)


I think it breaks policy but not the spec.

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.


This causes funny behavior like https://pbs.twimg.com/media/C6L3IvsUsAABuyS.jpg:large

Chrom(e|ium) will suggest to navigate to http://google if you're opening google.com


nice find, you should add this to that bug report


Not necessarily just a field trial. AFAIK it was bundled with a recent ChromeOS update, causing logon to fail when MITM'd


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.


> 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


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.

[1]: https://news.ycombinator.com/item?id=13751737


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.


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


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.


The issue only occurs in non-mitm mode, probably meaning the box doesn't actually do the TLS handsake, instead merely inspecting it.


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.


TLS 1.3 is still quite new, doesn't seem outrageous that they take a bit to implement it.


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


this is about cyanogen inc., not cyanogenmod.

tl;dr: CyanogenMod isn’t going anywhere


Your TL;DR is incorrect or misleading. CyanogenMod is dead.


No, it's just going to be rebranded and disconnected from the (dead) company cngn inc. - cyanogen himself even confirmed this on twitter


"It will come as no surprise that this most recent action from Cyngn is definitely a death blow for CyanogenMod."

https://www.cyanogenmod.org/blog/a-fork-in-the-road

It's a complete fork from CyanogenMod to be called Lineage.

https://github.com/lineageos


Plus Lineage seems like a much better brand name than CyanogenMod for mass adoption.

Though I would've called it Cyborg or something more analogous to Android.


I always thought "TrueBlueOS" would have been a good name for the open source version...


But then the confusion with TrueOS (prev. PC-BSD).


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


Exactly. When someone changes their name, we don't hold a funeral.


OVH DeskSaaS, 10€/mo for a decent box


Link please?


Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: