
HSTS Preload lists cause Chromium to think http://google/ is a valid domain - coderobe
https://bugs.chromium.org/p/chromium/issues/detail?id=698660
======
Animats
I warned about this back when all those new TLDs were being considered.
Single-word TLDs are not properly supported in browsers, in DNS, or even at
the glibc level.

At the browser level, is it a keyword or a domain? Try "ai". "ai" is a real
domain, and there's a web site at "[http://ai"](http://ai"), touting the
advantages of starting an offshore company in Anguilla. Most browsers
interpret "ai" as a search term by default. If you enter "ai.", though, you've
specified a rooted domain name (a feature few people know about) and should
get the "ai" web site. Firefox understands this, but Android doesn't. Try
various browsers.

At the glibc level, there's an exploitable bug, which I reported in 2012.[1]
It's still open. The bug was first seen in 2011 and reported on
serverfault.[2] The problem is that glibc DNS lookup has a feature which is
supposed to allow abbreviating domain names. The idea was that if you're on
"something.harvard.edu" and you look up "law", it tries "law.harvard.edu". The
exploit is that if you're on "foo.com", and you look up "baz.com, glibc tries
"baz.com.com". There's a domain "com.com", and it has a wildcard DNS server,
so it will resolve "baz.com.com". What's there? A scam. "You are selected by
G00GLE to be among the first few persons to win an iPhone 7...".

This behavior is a problem for all single word domains. Whether it is active
depends on the hostname of your local host. It's mostly a server problem, but
some ISPs issue clients hostnames such as "12345678.comcast.net", which means
that "google" gets tried as "google.comcast.net". Fortunately,
"google.comcast.net" doesn't resolve in DNS. Neither does "com.comcast.net"
ISPs need to be careful about this.

(It's a big problem if you're writing a web crawler, which is why I know about
it.)

[1]
[https://sourceware.org/bugzilla/show_bug.cgi?id=13935](https://sourceware.org/bugzilla/show_bug.cgi?id=13935)
[2] [http://serverfault.com/questions/341383/possible-nxdomain-
hi...](http://serverfault.com/questions/341383/possible-nxdomain-hijacking)

~~~
AndyMcConachie
This is a general problem with DNS search lists. The 'search' directive in
/etc/resolv.conf attempts to solve this, but is itself problematic.

This can also be set via DHCP.

[https://tools.ietf.org/html/rfc3397](https://tools.ietf.org/html/rfc3397)

[https://tools.ietf.org/html/rfc6106#page-7](https://tools.ietf.org/html/rfc6106#page-7)

~~~
Animats
It's a feature that should be off by default. It's only useful in corporate
intranets, where the corporate DHCP and DNS servers could provide a search
list for finding local servers.

------
mholt
A great case study in "The Web is hard."

I stumbled on this earlier this week:
[https://twitter.com/mholt6/status/838504217731948544](https://twitter.com/mholt6/status/838504217731948544)
and found it amusing but confusing in two ways:

1) The prompt is pointing to the "Secure" icon; I thought it was asking me if
I wanted to downgrade my protocol to HTTP.

2) The domain "google" made me and several others wonder if there was a hosts
file entry for "google", which turns out there isn't.

No, of course, the real problem is much more complicated; a strange twist of
omnibar meets DNS meets HSTS. This is definitely an edge case, but might be a
glimpse into the complicated future of gTLDs and the emergence of ever-more
web standards...

~~~
xg15
> _A great case study in "The Web is hard."_

Or alternatively "the web is hard if you sacrifice any kind of structure to
make a quick buck".

On the risk of sounding get-off-my-lawn-ish, but TLDs used to be assigned
using some relatively simple, service-agnostic rules: A hierarchical system
for ccTLDs, plus a small set of universal gTLDs plus some historic quirks.
Nowadays assignment seems to be solely by who pays most.

~~~
kogepathic
> On the risk of sounding get-off-my-lawn-ish

You don't. At least not to me. The new gTLDs are clearly a money grab on the
part of ICANN.

~~~
seanp2k2
I'm sure brands and attorneys love it. Now they have to defend Coke and Disney
and their hundreds of associated domains across hundreds of TLDs. Think of the
permutations.

------
marcosdumay
One very bad idea meets another.

Now, let's make every program more user friendly by obscuring the meaning of
our input fields and creating very complex rules for how they'll act... Oh,
wait, our programmers aren't able to understand our rules anymore? Nah, we are
an AI company, we can live with that.

------
unethical_ban
/Insert grumblings about insecurity of the omnibox (leaking internal corporate
data) and my personal preference for firefox-style URL box and search box.

~~~
nonsince
The FireFox URL box also acts as a search box, though

~~~
Aissen
Also, I find the firefox awesome bar much more powerful than Chrome's it does
(fuzzy?) word search on every url and title in the history, and here always
seem to give me more pertinent results than Chrome's (which seems to forget I
visited a website in just a few days).

~~~
freditup
I've found this exact same thing as well - the FF awesome bar always seems to
give me the results I want, whereas I have to do a lot more specific and
manual typing to find what I want in the Chrome bar. This could be an
interesting blog post I'd think: comparing the implementations of the matching
algorithms of Chrome vs. FF vs. possible others.

------
coderobe
This causes funny behavior like
[https://pbs.twimg.com/media/C6L3IvsUsAABuyS.jpg:large](https://pbs.twimg.com/media/C6L3IvsUsAABuyS.jpg:large)

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

~~~
gr3yh47
nice find, you should add this to that bug report

------
zeveb
Honestly, although I use the Omnibox/Awesome Bar/whatever a lot, I think it is
ultimately a mistake: there are too many search terms which end up resolving
to domains, esp. for a developer — and it was never a problem to just click in
the search bar before I ruined my muscle memory and started clicking in the
location bar instead.

One of these days I'll just disable it altogether.

------
draw_down
I understand why we have the omnibox, but worth pointing out that this problem
was solved long ago when URL & search bars were separate.

------
rnhmjoj
Is a TLD alone technically a valid host name?

~~~
coderobe
It would probably work, but it would break spec.

~~~
sesutton
It definitely works [http://ai](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.

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

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

------
coderobe
To whoever edited my title: The bug report title is inaccurate. It's
specifically about HSTS preloads, which is why my original title stated that
instead of "gTLDs".

~~~
mike-cardwell
The title as it appears on Hacker News isn't supposed to be "useful". It is
supposed to be the same as the source page. Idiotic, I know.

~~~
Outpox
That's not what I understood of reading the posting guidelines [0] and
especially "Otherwise please use the original title, unless it is misleading
or linkbait."

If OP thought it was misleading, then he was right to adjust it?

[0]
[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

~~~
dsp1234
Indeed the "title" of the original page is misleading (because the original
bug submitter thought it was one issue, but was really another).

And that has had the effect that most of the conversation in this thread is
about gTLDs instead of HSTS redirects, when the bug has nothing to do with the
former (as noted by the comments where they specifically say that this does
not happen to other gTLDs)

