Chrome 63 forces .dev domains to HTTPS via preloaded HSTS

Mattias Geniar, Sunday, September 17, 2017 - last modified: Wednesday, December 13, 2017

tl;dr: Chrome 63 (out since December 2017), will force all domains ending on .dev (and .foo) to be redirected to HTTPS via a preloaded HTTP Strict Transport Security (HSTS) header.


This very interesting commit just landed in Chromium:

Preload HSTS for the .dev gTLD.

This adds the following line to Chromium's preload lists;

{ "name": "dev", "include_subdomains": true, "mode": "force-https" },
{ "name": "foo", "include_subdomains": true, "mode": "force-https" },

It forces any domain on the .dev gTLD to be HTTPs.

Wait, there's a legit .dev gTLD?

Yes, unfortunately.

It's been bought by Google as one of their 100+ new gTLDs. What do they use it for? No clue. But it's going to cause a fair bit of confusion and pain to webdevelopers.

The .dev gTLD has nameservers and is basically like any other TLD out there, we as developers just happen to have chosen that name as a good placeholder for local development, too, overwriting the public DNS.

$ dig +trace dev. NS
dev.			172800	IN	NS	ns-tld4.charlestonroadregistry.com.
dev.			172800	IN	NS	ns-tld5.charlestonroadregistry.com.
dev.			172800	IN	NS	ns-tld3.charlestonroadregistry.com.
dev.			172800	IN	NS	ns-tld2.charlestonroadregistry.com.
dev.			172800	IN	NS	ns-tld1.charlestonroadregistry.com.

Google publishes some of their domains on there, too;

$ dig +trace google.dev A
google.dev.		3600	IN	A	127.0.53.53

So yes, it's a legit TLD.

Consequences of redirecting .dev to HTTPS

A lot of (web) developers use a local .dev TLD for their own development. Either by adding records to their /etc/hosts file or by using a system like Laravel Valet, which runs a dnsmasq service on your system to translate *.dev to 127.0.0.1.

In those cases, if you browse to http://site.dev, you'll be redirect to https://site.dev, the HTTPS variant.

That means your local development machine needs to;

  • Be able to serve HTTPs
  • Have self-signed certificates in place to handle that
  • Have that self-signed certificate added to your local trust store (you can't dismiss self-signed certificates with HSTS, they need to be 'trusted' by your computer)

Such fun.

What should we do?

With .dev being an official gTLD, we're most likely better of changing our preferred local development suffix from .dev to something else.

If you're looking for a quick "search and replace" alternative for existing setups, consider the .test gTLD, which is a reserved name by IETF for testing (or development) purposes.

There's also an excellent proposal to add the .localhost domain as a new standard, which would be more appropriate here. It would mean we no longer have site.dev, but site.localhost. And everything at *.localhost would automatically translate to 127.0.0.1, without /etc/hosts or dnsmasq workarounds.

I do hope the Chromium team reconsiders the preloaded HSTS as it's going to have rather big implications for local webdevelopment.



Hi! My name is Mattias Geniar. I'm a Support Manager at Nucleus Hosting in Belgium, a general web geek & public speaker. Currently working on DNS Spy & Oh Dear!. Follow me on Twitter as @mattiasgeniar.


Share this post

Did you like this post? Will you help me share it on social media? Thanks!

Comments

Hanno Sunday, September 17, 2017 at 12:03 - Reply

A few comments from me.

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.

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.

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


    Weldon Sunday, September 17, 2017 at 15:36 - Reply

    @Hanno I think it’s silly to pay a CA for a development certificate. Even with the free services it’s silly; there’s literally nothing to be gained by having a third party “verify” your own identity to you. The right solution there is to implement an internal CA (which you should really be doing anyways) and install its signing certificate on your local browsers. Then you can secure anything you want locally, including just IP addresses.


      DevSecOps Jones Sunday, September 17, 2017 at 17:43 - Reply

      There is no cost to LetsEncrypt certificates, and using these is Development is appropriate.
      The hosts need not be reachable from the internet, you can use DNS records to prove domain ownership.

      I would be recommending use of globally trusted, gratis certificates on dev from LE.
      The certificate issuance process should use different key material for prod,
      but should be configured in the same way.
      Ideally production and development instances of your site should be created using a similar process but with different data sets.


        Fernando Sunday, September 17, 2017 at 18:52 - Reply

        You dont always want to expose your project names to public DNS or CT logs.
        also, Lets Encrypt API limits are so low , that using it in dev mode, would exhaust it in just 5 deploys.

        a better idea is to use something like hashicorp vault for CA management.


        Weldon Monday, September 18, 2017 at 22:04 - Reply

        There’s no financial cost to LetsEncrypt, but now you’re adding a trust dependency that you don’t have if you just run your own internal CA for internal PKI. It’s really surprising to me that apparently a lot of companies don’t do this; I had assumed it was universal.


    JB Friday, November 10, 2017 at 15:40 - Reply

    Hanno,

    since you highlighted this discussion in your latest newsletter, you need to understand that there are some very solid reasons for using unencrypted connections to physically secured (or not) test servers:

    A) The connection is so physically secure that no amount of crypto or DNS can do anything but hurt security. This is the case when mapping to 127.0.0.1 or any other address on or near your own machine.

    B) To debug the plaintext protocol carried over TLS etc. it is often necessary to inspect the packets with a tool such as tcpdump or WireShark. Encryption (and especially PFS encryption) intentionally prevents that and thus must be turned off in such laboratory tests.

    C) During development of a new device or server, there will often be points in time where the TLS integration has not yet been done.

    D) To ensure bulletproof HTTPS implementation on a website, developers need to test the mechanisms that redirect, block or otherwise handle incoming HTTP connections. Having the browser prevent the simulated mistake prevents testing the second and third layer of defense.


    Jens Monday, December 11, 2017 at 17:26 - Reply

    Stupid comment. What does google or anyone have to do with what .tld I use LOCALLY on MY MACHINE ? Think before you speak!

    Googles “nice guy” halo is really starting to look crooked. They make a lot of weird decisions affecting everyone on the web just because they can.


    leo Tuesday, January 16, 2018 at 07:09 - Reply

    Hell, you think that dev is stupid.
    But using hsts for no reason – that’s just disgusting. Moreover, it breaks things.


leonixyz Sunday, September 17, 2017 at 12:09 - Reply

another solution: change browser


hintss Sunday, September 17, 2017 at 12:24 - Reply

protip: you can type “badidea” at the https error screen to skip it, avoid using the mouse


WhyNoMas Sunday, September 17, 2017 at 18:11 - Reply

Changing browser and recommending your clients to do so is the way to go. Chrome is now what IE used to be.


Kees Sunday, September 17, 2017 at 19:56 - Reply

While I agree that this is not desirable, there is a specific TLD made for testing, .test (source: https://en.wikipedia.org/wiki/.test).


Mike Schinkel Monday, September 18, 2017 at 04:15 - Reply

Thanks for pointing this out.

As an aside, google.dev’s IP is not routable; see https://stackoverflow.com/a/25665936


    Aaron Cooper Monday, January 8, 2018 at 05:38 - Reply

    I do, on my test environment. Because that is it’s purpose. The same reason why I used .dev for development, not testing.

    Each to their own, but I find it a bit absurd to pass off the removal of a domain that has a phonetic link to the environment’s intention to use another one that has an entirely different intention.


John McCormack Monday, September 18, 2017 at 12:57 - Reply

Yeah… I’m using Chrome less and less, using Firefox more and more.


Loïc Lavoie Monday, September 18, 2017 at 19:08 - Reply

You guys should remove the recommandation for .localhost as an alternative. Chrome and Safari force loopback on the locahost domain and any subdomain in it.

This means that any adresses ending with .localhost will force redirect to 127.0.0.1 without querying DNS’s or your hosts file.

https://webmasters.stackexchange.com/questions/88636/why-does-chrome-resolve-websitename-localhost-as-localhost


    Guillaume Sunday, September 24, 2017 at 19:11 - Reply

    +1. I had this problem several month ago, and it’s totally blocking if you are using a virtual machine like Vagrant, with a specific local IP.

    I understand frustration from (not all) people who commented here, but using .dev could prevent you from scaling your project towards a centralized multisite with a variation on TLD. As Hanno said, IMHO best practice seems to be using https://dev.domain.tld for local dev of a live site, http://localhost%5B:PORT%5D/%5Bdomain/%5D or some specific IP redirected locally for a quick project development / code testing.


Zardoz Tuesday, September 19, 2017 at 10:13 - Reply

1. Drop Chrome, in fact drop evil google generally
2. use local.yourdomain.com with a *yourdomain.com cert for testing


Ashley Sheridan Tuesday, September 19, 2017 at 23:08 - Reply

To be fair, the .dev TLD was made available a long time ago, so any developer using it locally should have expected problems eventually. I hope everyone here has learnt a valuable lesson: never make assumptions about things you don’t have total control over.


    Braeden Friday, January 5, 2018 at 22:01 - Reply

    There shouldn’t be a problem with using any .tdn if you mod your host file because that will redirect any existing domain name to your local machine. The problem here is that chrome is forcing HTTPS for a local site. I have code in place to detect whether I am on development or production so that .dev doesn’t use the same settings on production. But chrome forces https for .dev when it shouldn’t.


vjanzen Wednesday, September 20, 2017 at 21:19 - Reply

The IP 127.0.53.53 is a name collision entry.


tim Thursday, September 21, 2017 at 00:07 - Reply

I used use .local then found out about the clash with Bonjour. Then I switched to .server for my local servers (so far so good) and .dev for my local development (oh dear). But fortunately I use a dnsmasq server and can switch it out for something else. I name things as their full production domain plus .dev on the end, and that’s been fine for now. Many of the web apps I work with require a single domain name hard coded into a config file (such is life) so there will be one-time pain of updating those. I would support an official .localhost if it didn’t introduce untold security holes.


Fuck You Thursday, September 21, 2017 at 04:16 - Reply

f**king stupid google, go f**king eat s**t. We are using .dev for develop domain in our company, and all of a suddent we can’t access our dev sites anymore, WTF. Bulls**t!!!!


Anh Tran Thursday, September 21, 2017 at 04:43 - Reply

Don’t know what Google is up to, but this is not a smart step. Affecting all the developers in the world with a simple commit. A millions of working hours will be wasted.


ian Hobbs Friday, September 22, 2017 at 00:01 - Reply

interesting…. I just always used .site domain


Google Stupid Friday, September 22, 2017 at 09:04 - Reply

Google is evil. If they do that, let’s use https://blisk.io


Matthias Monday, September 25, 2017 at 17:07 - Reply

People. Just use the domain that’s actually reserved for testing. .test. You can, of course, easily get valid certificates for that. They just need to be in the local certificate store. Laravel Valet does that autimatically. Others do, too.


Burak Thursday, November 9, 2017 at 23:04 - Reply

Wtf, I wasted my days to find the issue. I was about to clean reinstall my Mac.


foogle Thursday, December 7, 2017 at 12:04 - Reply

Yes WTF Google is trying to do? What a pain they are causing to developers like myself, I think they trying to monopolize and we’r like their puppets that they can control go to hell google.


Sierk Bornemann Thursday, December 7, 2017 at 15:49 - Reply

RFC 2606 (June 1999): Reserved Top Level DNS Names
https://tools.ietf.org/html/rfc2606

[quote]
[…]

2. TLDs for Testing, & Documentation Examples

There is a need for top level domain (TLD) names that can be used for
creating names which, without fear of conflicts with current or
future actual TLD names in the global DNS, can be used for private
testing of existing DNS related code, examples in documentation, DNS
related experimentation, invalid DNS names, or other similar uses.

For example, without guidance, a site might set up some local
additional unused top level domains for testing of its local DNS code
and configuration. Later, these TLDs might come into actual use on
the global Internet. As a result, local attempts to reference the
real data in these zones could be thwarted by the local test
versions. Or test or example code might be written that accesses a
TLD that is in use with the thought that the test code would only be
run in a restricted testbed net or the example never actually run.
Later, the test code could escape from the testbed or the example be
actually coded and run on the Internet. Depending on the nature of
the test or example, it might be best for it to be referencing a TLD
permanently reserved for such purposes.

To safely satisfy these needs, four domain names are reserved as
listed and described below.

.test
.example
.invalid
.localhost

“.test” is recommended for use in testing of current or new DNS
related code.

“.example” is recommended for use in documentation or as examples.

“.invalid” is intended for use in online construction of domain
names that are sure to be invalid and which it is obvious at a
glance are invalid.

The “.localhost” TLD has traditionally been statically defined in
host DNS implementations as having an A record pointing to the
loop back IP address and is reserved for such use. Any other use
would conflict with widely deployed code which assumes this use.

3. Reserved Example Second Level Domain Names

The Internet Assigned Numbers Authority (IANA) also currently has the
following second level domain names reserved which can be used as
examples.

example.com
example.net
example.org

[…]
[/quote]


Dani Thursday, December 7, 2017 at 18:06 - Reply

That decision is bullshit! Time for another browser.


Dan Friday, December 8, 2017 at 04:22 - Reply

Thank you for posting this article. I just wasted 3 hours of my life on this. Would have been nice if Google had just posted a simple error message. If not for your article, I don’t know what I would have done!


Marat Friday, December 8, 2017 at 09:22 - Reply

Thanks for info. Wasted hours on this


mostafa Saturday, December 9, 2017 at 11:26 - Reply

shit …
shiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiit
:|


Adam Patterson Sunday, December 10, 2017 at 23:09 - Reply

I don’t really get why chrome forces the HTTPS though? Personally, I have to set my prefered domain. I handle the redirection of HTTP to HTTPS.

And Google owning the .dev TLD is kinda shitty to force this change on people, Weather you think its good in the long run. I would bet that no one owns a .dev and you probably won’t.


Changedev Tuesday, December 12, 2017 at 02:43 - Reply

I opened a incognito window and still got redirected to https. Thought something broke something. Thank you for saving my day trying to figure this out. I can now spend the rest of the day changing all my wordpress installs. Yay, such fun.


angry guy Tuesday, December 12, 2017 at 09:04 - Reply

Chrome tech leads and managers are idiots


Tesh Tuesday, December 12, 2017 at 14:18 - Reply

Time to use Firefox again like back in the old days!


Chrome TD Tuesday, December 12, 2017 at 20:24 - Reply

What happened to not being evil Google??


Svetlana Wednesday, December 13, 2017 at 11:29 - Reply

Saved my day. Thanks! I wonder why still no word from Google, would have been nice to hear something like “Hey webdevs, ditch your .dev-s, because now we rule your domain”… But no, of course, all of a sudden I just can’t reach my dev ground any more, as it’s all httpsssssed


    Tyler Reed Thursday, December 14, 2017 at 17:41 - Reply

    That, and some people have a “dev” environment AND a “test” environment. One of the projects I’ve worked one needed 6 environments (for coding, testing, acceptance, staging, etc.). Making our local sites end in “.test” would confuse our staff into thinking that our development environment is our test environment.


Cysioland Wednesday, December 13, 2017 at 19:52 - Reply

They urge people to use domains like .test, but also disallow these in their OAuth redirects.


Tamas Amon Thursday, December 14, 2017 at 00:22 - Reply

I made:
valet domain test
And now I using every directory with .test and not .dev
Not a nice feature form google chrome


ChromeDeveloper Thursday, December 14, 2017 at 12:30 - Reply

I have no words


Klaus Donnert Thursday, December 14, 2017 at 14:52 - Reply

I just switched to Firefox. Problem solved.


Alex Thursday, December 14, 2017 at 16:36 - Reply

I hate other browsers but i going to use safari or something.


Alexander Thursday, December 14, 2017 at 18:11 - Reply

Wasted half a day trying to reach my dev site… I use it with https but it still doesn’t work.
Although you said that “Have that self-signed certificate added to your local trust store (you can’t dismiss self-signed certificates with HSTS, they need to be ‘trusted’ by your computer)”
I’ve added certificate to my windows machine but it still doesn’t work.
Could someone, please, explain what is the correct way to add certificate “local trust store” so that I can continue to use .dev site via https?


Noname Friday, December 15, 2017 at 15:41 - Reply

Google idiots!!!!!!!!!!!!!!!!!!!!!!!!!!!!!


google idiot Friday, December 15, 2017 at 17:16 - Reply

down grade google chrome fuck you google idiots


Alex Friday, December 15, 2017 at 17:32 - Reply

Hey, Google, why only .dev & .foo? Go on, redirect all domains to https…
Couple of idiots in Google tell me what TDLs I should use for develop.


Bruce Klein Friday, December 15, 2017 at 23:54 - Reply

Thank you for publishing this explanation.


TobiVino Saturday, December 16, 2017 at 06:34 - Reply

Same thing goes with .app prefix , damn chrome


Digital Apps Sunday, December 17, 2017 at 11:52 - Reply

so glad i found this article, half a day wasted on configuring my apache. google, its a bad idea.


Masa Sunday, December 17, 2017 at 15:39 - Reply

Crome team literally hate developers. :( They have made impossible configure self-verify certificates and now this. All this no other reason other than being ash. What it’s them what I do my computer?

There is cost LetsEncrypt certificates you haw to pay domain.


Kevin Monday, December 18, 2017 at 12:11 - Reply

Very thankful for this article, wasted several hours on this…


Emanuele Ciriachi Monday, December 18, 2017 at 13:09 - Reply

Well this is some annoying nonsense right here. Goodbye Chrome, welcome Brave.


toddz Monday, December 18, 2017 at 21:31 - Reply

Is there a Chrome Extension that can fix this – to allow “.dev” domains locally? I want to stay in Chrome because I like its Dev Tools, and changing the “.dev” to “.test” in all my databases would be a huge pain.


Jalcide Wednesday, December 20, 2017 at 19:01 - Reply

Ugh. This is so irksome. Of course Google’s update rolled out at the exact moment I updated my VM, sending me on a red herring goose chase.

I refuse to use .test, on principle. I’m not TESTing, I’m DEVeloping.

The .dev gTLD shouldn’t even be a thing. Clearly, it should be reserved for developing.

What alternative (not .test nor .localhost) are people using?


Thomas Wood Wednesday, December 20, 2017 at 19:48 - Reply

*.localhost (properly referred to as “localhost.”) is already defined in RFC6761 https://tools.ietf.org/html/rfc6761 to always resolve to the local loopback interface. The linked proposal RFC forces DNS resolvers to not use the domain search list if they encounter “localhost” as the final portion of the requested address, and to assume that “localhost.” (the localhost TLD) was intended.

Google are planning to open *.dev for public registration in early 2018: https://www.registry.google/


FML Thursday, December 21, 2017 at 04:02 - Reply

WARNING: You can’t use a *.test domain when testing OAuth redirects. E.g. You’re developing an app that uses Google calendar where the user has to authorize your app tapping into user’s account.

Check out what @Cysioland said above: “They [Google] urge people to use domains like .test, but also disallow these in their OAuth redirects.”


FML Thursday, December 21, 2017 at 04:04 - Reply

WARNING: You can’t use a *.test domain when testing OAuth redirects. E.g. You’re developing an app that uses Google calendar where the user has to authorize your app tapping into user’s account.

Check out what @Cysioland said above: “They [Google] urge people to use domains like .test, but also disallow these in their OAuth redirects.”

UPDATE: corrected email address, delete my other post if you wish.


Charan Thursday, December 21, 2017 at 13:21 - Reply

As Developer i will continue to use *.dev for Developemnt setup , what ever the google has to do with .dev domain let them do still localhost is all ours to lay rules !


jmandawg Thursday, December 21, 2017 at 13:25 - Reply

Unfortunately there is a bug, this also redirects http://dev/ (where dev is an entry in my hosts file) to https which is not *.dev


Ali Saturday, December 23, 2017 at 23:09 - Reply

I’m using dnsmasq and nginx to test my codes locally, I use self signed certificates for all .dev domains too.
The problem is that Chrome shows following error everytime I want to access my local domains:

Your connection is not private
Attackers might be trying to steal your information from *****.dev (for example, passwords, messages, or credit cards). Learn more
NET::ERR_CERT_COMMON_NAME_INVALID

No more information.
Thank you google for ruining my development environment for the whole week :|


Chris Monday, January 1, 2018 at 02:02 - Reply

site.localhost doesn’t work in latest Chrome either but site.test works


Dave Wednesday, January 3, 2018 at 12:11 - Reply

Ow goody. Google better bring out a patch where you’re able to easily switch this off… within the development inspect window or something. Cause developing != testing. I’ve got .dev .test and .preprod urls that I use in my workflow and this move sh*ts all over that. Happy new year!


Gazsi Friday, January 5, 2018 at 19:22 - Reply

say goodby to chrome, welcome to new firefox


steve Thursday, January 18, 2018 at 15:22 - Reply

Oh well, that explains the last few hours of frustration.
I cant just ditch chrome, the dev tools are better and I use it in automated testing as well.
I guess i am going to have to sort out a self-signed cert solution – anyone have any pointers?


Leave a Reply

Your email address will not be published. Required fields are marked *