.test is an official IANA reserved special-use domain name that will never be delegated out. Use it. Problem solved.<p>I don't know why people thought they could start using random TLD's on their own, there was always the risk they could be delegated officially.<p><a href="https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml" rel="nofollow">https://www.iana.org/assignments/special-use-domain-names/sp...</a>
Hey everyone. I'm the Tech Lead of Google Registry and I'm the one behind this (and likely future) additions to the HSTS preload list. I might be able to answer some questions people have.<p>But to pre-emptively answer the most likely question: We see HTTPS everywhere as being fundamental to improving security of the Web. Ideally all websites everywhere would use HTTPS, but there's decades of inertia of that not being the case. HSTS is one tool to help nudge things towards an HTTPS everywhere future, which has really only become possible in the last few years thanks to the likes of Let's Encrypt.
Use .localhost pointing at 127.0.0.1 for local development. It is reserved for this purpose and obvious to everyone unlike .test.<p>For reference your options are:<p><pre><code> .test
.example
.invalid
.localhost
</code></pre>
<a href="https://tools.ietf.org/html/rfc2606" rel="nofollow">https://tools.ietf.org/html/rfc2606</a><p>With only .localhost fitting the purpose of most people's usage of .dev.
Just commented over at Matthias' blog, I'll just copy-paste it here:<p>First of all I think this is generally a good move. If people use random TLDs for testing then that’s just bad practice and should be considered broken anyway.<p>But second I think using local host names should be considered a bad practice anyway, whether it’s reserved names like .test or arbitrary ones like .dev. The reason is that you can’t get valid certificates for such domains. This has caused countless instances where people disable certificate validation for test code and then ship that code in production. Alternatively you can have a local CA and ship their root on your test systems, but that’s messy and complicated.<p>Instead best practice IMHO is to have domains like bla.testing.example.com (where example.com is one of your normal domains) and get valid certificates for it. (In the case where you don’t want to expose your local hostnames you can also use bla-testing.example.com and get a wildcard cert for *.example.com. Although ultimately I’d say you just shouldn’t consider hostnames to be a secret.)
They should do the opposite. There should be a .insecure domain where browsers accept HTTP or HTTPS with wrong or no certs, and pretend it is HTTPS with all consequences (e.g. loading of HTTPS third party resources). I wouldn't put it on the open net, but rather let people set it up internally for testing.
Just as a note; .dev is not <i>yet</i> an official TLD, it's on the status "proposed" which means that google is basically the highest priority on the waiting list.<p>.foo is delegated and thusly a full TLD, yes.<p>On the other hand, you should not be using .localhost if the target is not running on your loopback interface, resolving localhost to anything but loopback is considered harmful.<p>I find .test or .intranet to be more useful for such installations, they are either designated as "cannot be a TLD" or are very very unlikely to become a TLD, respectively.
For my development needs, I try to either:<p>* Publish mDNS records to give myself extra `.local` names, or
* Get a wildcard published in the organisation's internal DNS<p>If you can't do either of those, _please_ use `.test` as your test TLD, as it's explicitly set aside for that purpose so you know you're never going to collide with anyone.<p><a href="https://tools.ietf.org/html/rfc2606#page-2" rel="nofollow">https://tools.ietf.org/html/rfc2606#page-2</a>
The article mentions as workaround:<p><i>That means your local development machine needs to;<p>- Be able to serve HTTPs<p>- Have self-signed certificates in place to handle that<p>- You'll have to click through the annoying unsecure site window every time<p>Such fun.</i><p>Part of HSTS is the requirement that certificate warnings become unskippable. So the above wouldn't work - you'll need an actual CA-signed certificate that is accepted by the browser, otherwise, you won't be able to access the site.
This is perfect and great. I'd love to see gradually (yes, GRADUALLY, without breaking anything!) all TLDs do this.<p>".localhost" has existed and been popular for local development for MANY years. I've no idea why somebody would use `.dev, but now that it's a registered TLD, using it locally is just asking for trouble.<p>Also, you can just use 127.0.0.1, 127.0.0.2, 127.0.0.3, etc.
I’ve never used .dev - but going back five or six years we set up a .dev sub domain of our domain and use that exclusively for development.<p>dev.ourdomain.net is a web-accessible server on our local network, configured as the dns server for that sub domain and is our internal CA trusted to issue the certs we use for development.
We have always used local.{site}.com as a sub domain rather than tld. Makes CORS rules simpler, and we actually have a real dns record pointing to 127.0.0.1 so we don't have to bother with HOSTS
With .test thrown around a lot, would there be any complementary support from browser vendors for that TLD to be specifically a development tld? localhost is recognised to be one by chrome for example, that's the only domain where html5 geo api works without https, and "your passwords are transferred via plain text" is not displayed. In order to help shift to .test google might alter it's heuristics to recognise .test as a common tld used for development.
The main issue here is how much of a PITA it is to work with HTTPS locally (totally true that .dev is the wrong thing to use for dev boxes here). Self signing certs and forcing /etc/resolver/ configs is only half of it. Then you run into trouble with mobile emulators, proxying, etcetc.<p>We have an automated setup of it for devs, but it's out of necessity rather than anything else. It's a pain to deal with.
I don't really see this as a problem. In fact, I wish Chrome would do that for <i>every</i> gTLD, but obviously that's not going to happen any time soon. Secure by default would be great.<p>The real issue (for me at least) is that it's far too much of a pain to run an SSL secured site locally. It can be done, but doesn't work well across teams given you need to register your certificates locally. Being able to serve a site from a Vagrant box or a Docker container over https in a way that a browser will accept (or even just pretend to accept) would be immensely helpful. I'm sure web developers and browser vendors are trying to resolve the problem already, but it can't come soon enough in my opinion.
*.localhost is a cool idea, would be cool if it allowed self-signed certificates as valid, or even have the browser do some magic and pretended it had an ssl certificate.
<p><pre><code> Sorry for top-leveling a grand-child comment, but reading between
the lines, this is the attack vector:
> And for the last question: Again, there are no .dev domain
> names. There never have been. It's never been available for
> registration. The recommendation for a long time has been to
> only use either (a) domain names that you actually own, or (b)
> domain names that are reserved for testing and are guaranteed
> never to exist a la RFC 2606. Using domain names for testing
> that don't yet exist but could in the future is a huge security
> hole that you must fix now. Do it now while the domain names
> still fail to resolve. Once they resolve, and you don't own
> them, then your security situation gets a lot worse.
Google is concerned with nation-state attacks. This means they
have to assume ninja-assassin-scuba-divers have tapped all their
cables underground. They're also concerned about
ninja-assassin-usb-stick-droppers, and all kinds of other use
cases.
What they're doing is:
1) Requiring *.dev to match PRE-LOADED HSTS certs. This allows
google to "safely" boot up a computer from scratch. Just so long
as "clone-a-computer-from-scratch.dev" matches the
public/private handshake for HSTS/HTTPS then google knows that no
MITM, no nation state DNS takeover, etc. is possible.
So long as the VERY FIRST CONTACT WITH THE INTERNET is a *.dev
domain, then that computer can be "as secure as possibly known".
2) Forcing people to bounce "off" of invalid TLD's as a network
administration method.
Remember, google is concerned about nation states. Remember
wanna-cry? How it was disabled by some random researcher
registering xyz-abc-123.com?
That attack costs $15. Now imagine a nation-state, intentionally
registering a gTLD of "\*.haha-now-your-company-infra-is-pwnd"
which they somehow glean is the gTLD your developers use for
local development / testing / intranet portal.
If you could spoof IBM's intranet by doing something like:
"http://www.welcome.ibm" or "https://www.welcome.ibm" (b/c the
*.ibm wasn't cert-pinned.....) then you could trivially cause
*.ibm to resolve to some sort of spoofed site to collect
passwords. Or what if they're catching `mysql -uroot -pxyz
staging.product.ibm`? Whoops.
Or... perhaps another gTLD we'll see google register is "*.go" or
maybe their internal builds of chrome already do cert-pinning on
that. (Reason is I've seen/heard they allow
'http://go/my-internal-shortlink' ... I know that other tech
companies have had similar setups).
Same attack vector. You control the DNS, you control ALL
responses. And when somebody types www.microsoft.com, it may be
_impossible_ to know if that "Down for Maintenance" banner is
real or fake if their DNS is controlled by somebody who really is
your enemy.</code></pre>
I test with HTTP, locally.<p>This forcing of opinionated things goes on my nerves. How about develop the browser, and let the mass decide what they use. Amazon was 100% HTTP for 20 years (except the single login page) - it worked very well.
The most annoying part here is that Google isn’t even using .dev as public TLD – they purely use it for internal testing, and all registered .dev domains resolve to 127.x.x.x addresses.<p>.dev should have been entirely reserved, or made available publicly. Registering a TLD just for your own internal testing, and forcing everyone to switch away, is the most user unfriendly move you can do.