Google Chrome Now Forces All .dev Domains to HTTPS

15 December 2017

With the release of Chrome 63, all .dev domains are now redirected to HTTPS via a preloaded HTTP Strict Transport Security (HSTS) header. It's something that has been coming down the pipe for a while now, but has still surprised many.

What does this mean?
This means that if Chrome is your preferred browser and you like to use .dev domains for local development apps, you won't be able to without installing an SSL certificate locally.

Google Owns the .dev TLD

.dev is one of many top level domains (TLDs) owned by Google. As part of their push for universal encryption, Google is adding the HSTS header on this and many TLDs, including .foo and .app among others. You can read more about the initiative in Google's "Broadening HSTS to Secure More of the Web" post on their Security blog.

Well That Sucks

Yes. Yes it does. Why? Because now if I want to keep using .dev locally, I have to install a valid SSL certificate locally. I should be clear that I support Google's push for universal encryption, but this complicates things for anybody like me who is accustomed to using .dev domains for local development. And I think it's fairly safe to assume that the majority of .dev use-cases involve local development.

Does encryption really matter when working locally? It's debatable and depends on the project. For the vast majority of my use-cases, it doesn't.

Some will say, "Just install a self-signed cert on your local machine." Sure, I could do that, but when everything is running in containers, it gets complicated and isn't something I want to have to do for dev apps that don't really need SSL.

Others will say, "Just don't use Chrome." That's definitely an option, especially with the recent FireFox update, but it's likely only a temporary solution. It's only a matter of time before other browsers begin fully enforcing HSTS TLDs too.

What Can Be Done?

Not a whole lot, really. Google owns the .dev TLD and can do what they want with it. You can setup local SSL certs if you really want to go that route, but for me, I've just starting using a different TLD for my dev apps.

How Does This Affect Nanobox?

The .dev TLD is something we adopted early on here at Nanobox and included in all our guides and documentation related to running apps locally. With HSTS on .dev domains, SSL certificates are required. While it is possible to install certificates for local testing with Nanobox (as outlined by Dan Hunsaker here), it's not simple. There are a few problems:

Nanobox is designed to terminate SSL in a router/load-balancer, which isn't provided for local dev apps; only live and dry-run apps (which actually do get a self-signed cert).

nanobox run sessions run inside of a "code" container that is designed to be ephemeral and transient. Even if a certificate was installed, it would get wiped every time the container gets replaced (which is often).

New TLD Recommendations

Our recommendation is to move away from the .dev TLD for local development apps. We've updated our guides and documentation to use new TLDs when adding DNS aliases for both dev apps and dry-run apps and we're in the process of updating Nanobox quickstart READMEs to do the same. The most recent version of Nanobox Desktop (the Nanobox CLI) now prevents you from adding .dev domains as DNS aliases.

The following are our new TLD recommendations for dev and dry-run apps:

.local for development

.test for dry-run

Pro-Tip: To keep browsers from treating.localand.testdomains as search terms, include the protocol when typing it into the URL field. For example:http://mydomain.localrather thanmydomain.local.