Home / ubuntu / Questions / 985283
In Process
Kar19
Asked: 2017-12-12 08:09:51 +0800 CST

Chrome loads my local hosted website as https instead of http resulting an error (started happening after an ubuntu update)

  • 772

I have a local wordpress project i am working on, and usually open my website by typing example.dev in the url bar, and my website i am working on displays properly.

I apt-get update and apt-get upgrade my ubuntu computer, and it requested a restart. after restarting - i try to open my local website and I get an error:

This site can’t be reached example.dev refused to connect. Try:

Checking the connection Checking the proxy and the firewall ERR_CONNECTION_REFUSED ReloadHIDE DETAILS Check your Internet connection Check any cables and reboot any routers, modems, or other network devices you may be using. Allow Chrome to access the network in your firewall or antivirus settings. If it is already listed as a program allowed to access the network, try removing it from the list and adding it again. If you use a proxy server… Check your proxy settings or contact your network administrator to make sure the proxy server is working. If you don't believe you should be using a proxy server: Go to the Chrome menu > Settings > Show advanced settings… > Change proxy settings… and make sure your configuration is set to "no proxy" or "direct."

and noticed it's serving my website as "https" instead of "http", whenever i edit the "https" to "http", after pressing enter it still loads it as https.

I wasn't so sure that this was the problem - so i opened firefox and did the same - and got a proper output of my website, having "http" at the begining and not "https".

What's causing this to happen in Chrome?

My website runs on an apache2 server. This didn't happen before the update.

edit: I came across this post - https://superuser.com/a/1251483/414388 and don't really understand why do i need to change my domain name - i really don't want to follow this method. this is not a solution.

networking

2 Answers

  1. If you navigate to the article posted in the superuser post, the tl;dr explains it:

    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.

    So your only solutions are to either change to something other than the .dev TLD, or create a certificate and implement HTTPS in your virtual host configuration for local development.

    In order to explain why that's your only solution, I'll need to start with what HSTS means and how it works.

    HSTS in General

    HSTS is a relatively new HTTP header, which when set, tells browsers that the next time someone navigates to the domain, only access it using HTTPS without the need for any server-side redirection.

    For example, let's consider that you navigated to http://example.com. In the response headers, you receive the following:

    Strict-Transport-Security: max-age=31536000

    This header tells the browser that, for the next year (31536000 seconds), when the user accesses http://example.com, redirect that URL to https://example.com locally without the need of any server redirects. And only then, access the site with https://example.com.

    HSTS for subdomains

    The previous is only valid for a single domain. So for example, if you try to access http://subdomain.example.com, the site would work without any redirects.

    To solve this, the previous header should be changed to:

     Strict-Transport-Security: max-age=31536000; includeSubdomains

    Now, even if you never accessed any subdomains of example.com, the browser will ALWAYS redirect subdomains to https before making a request.

    HSTS preloading

    The final step is to fix one last issue. The first time you ever access a site, you would still be accessing it using HTTP, which would redirect you to HTTPS and send you the HSTS header. This isn't secure and is still a security issue.

    To solve this, major browsers use Chrome's HTTP Strict Transport Security (HSTS) preload list to hardcode domains that can only be accessed with HTTPS. You can find the submission form here: https://hstspreload.org/

    The only modification you need to do before submitting your domain is to modify your header so it caches in browsers for at least 2 years, and add the preload option to it.

    Strict-Transport-Security: max-age=63072000; includeSubdomains; preload

    After you submit your domain, and once a new version of Chrome is released (or any other browser implementing Chrome's HSTS preload list, and not necessarily the next version), your domain will be hardcoded into Chrome as HTTPS-only.

    HSTS preloading for TLDs

    Owners of a TLD are allowed (and encouraged) to submit their whole TLD for HSTS preloading.

    Owners of gTLDs, ccTLDs, or any other public suffix domains are welcome to preload HSTS across all their registerable domains. This ensures robust security for the whole TLD and is much simpler than preloading each individual domain.

    And since Google owns the .dev TLD, they did just that. So now all *.dev domains will only work in HTTPS under Chrome. And since most browsers use the same preload list, those browsers will stop working as well.

    If you search the list of preloaded domains (CAUTION: The page is over 40MB and will take a while to render. So your computer might freeze if it isn't powerful enough!), you can find that the TLDs are preloaded: google, dev, foo, page, app, chrome.

    // eTLDs
// At the moment, this only includes Google-owned gTLDs,
// but other gTLDs and eTLDs are welcome to preload if they are interested.
{ "name": "google", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true, "pins": "google" },
{ "name": "dev", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true },
{ "name": "foo", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true },
{ "name": "page", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true },
{ "name": "app", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true },
{ "name": "chrome", "policy": "public-suffix", "mode": "force-https", "include_subdomains": true },
    • 4

  2. In case you are out of the options to change your current .dev domain, you can downgrade your Chrome to version 61 (I've did it successfully => here)

    • 0