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 and podcaster. Currently working on DNS Spy. Follow me on Twitter as @mattiasgeniar.

I respect your privacy and you won't get spam. Ever.
Just a weekly newsletter about Linux and open source.

SysCast podcast

In the SysCast podcast I talk about Linux & open source projects, interview sysadmins or developers and discuss web-related technologies. A show by and for geeks!

cron.weekly newsletter

A weekly newsletter - delivered every Sunday - for Linux sysadmins and open source users. It helps keeps you informed about open source projects, Linux guides & tutorials and the latest news.

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 (permalink)

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

Reply


    Weldon Sunday, September 17, 2017 at 15:36 (permalink)

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

    Reply


      DevSecOps Jones Sunday, September 17, 2017 at 17:43 (permalink)

      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.

      Reply


        Fernando Sunday, September 17, 2017 at 18:52 (permalink)

        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.

        Reply


          Anmol Sunday, September 17, 2017 at 21:57 (permalink)

          The API limits are not that low? Just don’t recreate a new certificate every time you launch the app, reuse old ones.

          Reply


        Weldon Monday, September 18, 2017 at 22:04 (permalink)

        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.

        Reply


    JB Friday, November 10, 2017 at 15:40 (permalink)

    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.

    Reply


    Jens Monday, December 11, 2017 at 17:26 (permalink)

    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.

    Reply


leonixyz Sunday, September 17, 2017 at 12:09 (permalink)

another solution: change browser

Reply


    Michal Špaček Tuesday, September 19, 2017 at 19:56 (permalink)

    Which one? The same HSTS preload list is used for Chrome (and Chromium-based browsers), Firefox, IE/Edge, Safari and probably some more. Sooner or later all these will force HTTPS for .dev.

    Reply


hintss Sunday, September 17, 2017 at 12:24 (permalink)

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

Reply


    Emil Stahl Wednesday, September 20, 2017 at 00:35 (permalink)

    Yes. But you can’t skip HSTS. That is part of the whole idea 💡

    Reply


      anon Wednesday, September 20, 2017 at 06:07 (permalink)

      You can, in fact, skip HSTS errors using the ‘badidea’ method in Chrome. Quick way to confirm is https://subdomain.preloaded-hsts.badssl.com/ , which is an HSTS enabled test page provided by the badssl.com test service. Clicking ‘Advanced’ gives you the normal text, but typing ‘badidea’ takes you to the page.

      What’s interesting, most of badssl.com’s test URLs give you an actual webpage explaining why the SSL should or should not have worked. In this case, you just get an nginx error page, suggesting that perhaps even the folks at badssl.com was not aware Chrome (or anyone else) provided an HSTS bypas.

      Reply


        Dustin Thursday, December 7, 2017 at 22:12 (permalink)

        But if you’re using .dev for development work and you’re not even server on over https, `badidea` won’t work because you just get a network connection error.

        Reply


WhyNoMas Sunday, September 17, 2017 at 18:11 (permalink)

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

Reply


Kees Sunday, September 17, 2017 at 19:56 (permalink)

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

Reply


Mike Schinkel Monday, September 18, 2017 at 04:15 (permalink)

Thanks for pointing this out.

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

Reply


Ryan Monday, September 18, 2017 at 05:54 (permalink)

Use .test or gtfo.

Reply


John McCormack Monday, September 18, 2017 at 12:57 (permalink)

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

Reply


Loïc Lavoie Monday, September 18, 2017 at 19:08 (permalink)

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

Reply


    Guillaume Sunday, September 24, 2017 at 19:11 (permalink)

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

    Reply


Zardoz Tuesday, September 19, 2017 at 10:13 (permalink)

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

Reply


    ak Wednesday, December 13, 2017 at 16:50 (permalink)

    And I hope google will eventually learn the lesson; Don’t break the web!

    Reply


Ashley Sheridan Tuesday, September 19, 2017 at 23:08 (permalink)

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.

Reply


vjanzen Wednesday, September 20, 2017 at 21:19 (permalink)

The IP 127.0.53.53 is a name collision entry.

Reply


tim Thursday, September 21, 2017 at 00:07 (permalink)

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.

Reply


Fuck You Thursday, September 21, 2017 at 04:16 (permalink)

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!!!!

Reply


Anh Tran Thursday, September 21, 2017 at 04:43 (permalink)

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.

Reply


ian Hobbs Friday, September 22, 2017 at 00:01 (permalink)

interesting…. I just always used .site domain

Reply


Google Stupid Friday, September 22, 2017 at 09:04 (permalink)

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

Reply


    wut Friday, September 22, 2017 at 15:49 (permalink)

    … Blisk is build on Chromium…

    Reply


Matthias Monday, September 25, 2017 at 17:07 (permalink)

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.

Reply


Burak Thursday, November 9, 2017 at 23:04 (permalink)

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

Reply


foogle Thursday, December 7, 2017 at 12:04 (permalink)

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.

Reply


Sierk Bornemann Thursday, December 7, 2017 at 15:49 (permalink)

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]

Reply


Dani Thursday, December 7, 2017 at 18:06 (permalink)

That decision is bullshit! Time for another browser.

Reply


Dan Friday, December 8, 2017 at 04:22 (permalink)

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!

Reply


Marat Friday, December 8, 2017 at 09:22 (permalink)

Thanks for info. Wasted hours on this

Reply


mostafa Saturday, December 9, 2017 at 11:26 (permalink)

shit …
shiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiit
:|

Reply


Adam Patterson Sunday, December 10, 2017 at 23:09 (permalink)

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.

Reply


Changedev Tuesday, December 12, 2017 at 02:43 (permalink)

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.

Reply


angry guy Tuesday, December 12, 2017 at 09:04 (permalink)

Chrome tech leads and managers are idiots

Reply


Tesh Tuesday, December 12, 2017 at 14:18 (permalink)

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

Reply


Chrome TD Tuesday, December 12, 2017 at 20:24 (permalink)

What happened to not being evil Google??

Reply


Svetlana Wednesday, December 13, 2017 at 11:29 (permalink)

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

Reply


Cysioland Wednesday, December 13, 2017 at 19:52 (permalink)

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

Reply


Tamas Amon Thursday, December 14, 2017 at 00:22 (permalink)

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

Reply


ChromeDeveloper Thursday, December 14, 2017 at 12:30 (permalink)

I have no words

Reply


Klaus Donnert Thursday, December 14, 2017 at 14:52 (permalink)

I just switched to Firefox. Problem solved.

Reply


Alex Thursday, December 14, 2017 at 16:36 (permalink)

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

Reply


Leave a Reply

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