Chrome 63 changing http to https

Question

Does using Chrome v.63 force use of https?

I am running Apache 2.4.27 on a Windows 10 desktop as a sandbox where I can experiment and do some tutorials. I have a virtual host setup called www.tutorial.dev with an alias of tutorial.dev. In the Windows 10 hosts file I have set up www.tutorial.dev and tutorial.dev to point to localhost.

As of yesterday the url http://tutorial.dev/Bootstrap4FromScratch/ was working normally. In this case providing a directory listing as a jump off point into various examples and exercises. Today, when I type in the url Chrome changes it to https and I get a connection refused message.

I understand the connection refused message. There are no certificates setup.

The only change I can find is that Chrome changed from v.62.x to v.63.x. What in Chrome 63 could be forcing http to https?

I don't have this problem with MS Edge. I tested another similar configuration on a different machine that was in the process of downloading Chrome 63.x. It already had 62.x installed. It worked until the 63.x upgrade was complete then the same problem occurred.

Additional information: If I use http://localhost to bring up the index.html or version.php in the htdocs directory the switch from http to https does not happen. The virtual host www.tutorial.dev resides in another directory outside of htdocs.

If this has been asked and answered please point me to the question/answer thread.

Thanks in advance,

Barry

Answer 1

Google owns the .dev TLD and with Chrome 63 they are forcing HTTPS on all requests to anything.dev

I went through my local dev setup and replaced all references to .dev with .local, works fine now.

Your other option is to use Firefox for local development. .dev now triggers https in FF (since before FF61) with a workaround

Edit (asside): I have switched to using .localhost for dev as browsers allow navigator.geolocation.getCurrentPosition() (blocked if site is not HTTPS).

Answer 2

Google Chrome 63 update, out December 2017, places .dev domains in the preloaded HSTS list with a rule enforcing HTTPS, no workarounds.

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

The "only" way is to switch .dev with something else, like .localhost

IETF states a few reserved TLDs for development:

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.

PS: .foo is also in the preloaded HSTS list