O Chrome carrega meu site hospedado local como https em vez de http, resultando em um erro (iniciado depois de uma atualização do ubuntu)

3

Eu tenho um projeto wordpress local em que estou trabalhando, e geralmente abro meu site digitando example.dev na barra de URL, e meu site que estou trabalhando é exibido corretamente.

Eu apt-get update e apt-get upgrade meu computador ubuntu e solicitei uma reinicialização. depois de reiniciar - tento abrir meu site local e recebo um erro:

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

e notei que ele está servindo meu site como "https" em vez de "http", sempre que eu edito o "https" para "http", depois de pressionar Enter ainda carrega como https.

Eu não tinha tanta certeza de que esse era o problema - então eu abri o firefox e fiz o mesmo - e obtive uma saída adequada do meu site, tendo "http" no começo e não "https".

O que está causando isso no Chrome?

Meu site é executado em um servidor apache2. Isso não aconteceu antes da atualização.

edit: me deparei com este post - link e realmente não entendo porque eu preciso mudar meu nome de domínio - eu realmente não quero seguir este método. isso não é uma solução.

    
por Kar19 11.12.2017 / 17:09

2 respostas

3

Se você navegar para o artigo publicado no post de superusuário, o tl; dr explica:

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.

Assim, suas únicas soluções são mudar para algo diferente de .dev TLD ou criar um certificado e implementar HTTPS em seu configuração do host virtual para desenvolvimento local.

Para explicar por que essa é sua única solução, precisarei começar com o que significa a HSTS e como ela funciona.

HSTS em geral

O HSTS é um relativamente novo cabeçalho HTTP, que, quando configurado, diz aos navegadores que na próxima vez que alguém navegar para o domínio, acessá-lo apenas usando HTTPS sem a necessidade de redirecionamento do lado do servidor. / p>

Por exemplo, vamos considerar que você navegou para http://example.com . Nos cabeçalhos de resposta, você recebe o seguinte:

Strict-Transport-Security: max-age=31536000

Esse cabeçalho informa ao navegador que, no ano seguinte (31536000 segundos), quando o usuário acessar http://example.com , redirecionará essa URL para https://example.com localmente, sem a necessidade de redirecionamentos de servidor. E só então, acesse o site com https://example.com .

HSTS para subdomínios

O anterior é válido apenas para um único domínio. Por exemplo, se você tentar acessar http://subdomain.example.com , o site funcionaria sem redirecionamentos.

Para resolver isso, o cabeçalho anterior deve ser alterado para:

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

Agora, mesmo que você nunca tenha acessado nenhum subdomínio de example.com , o navegador redirecionará SEMPRE subdomínios para https antes de fazer uma solicitação.

Pré-carregamento de HSTS

O passo final é corrigir um último problema. A primeira vez que você acessar um site, você ainda o acessaria usando HTTP, o que o redirecionaria para HTTPS e lhe enviaria o cabeçalho HSTS. O anterior não é seguro e ainda é um problema de segurança.

Para resolver isso, os principais navegadores usam a lista de pré-carregamentos HTTP Strict Transport Security (HSTS) do Chrome para codificar domínios que só podem ser acessados com HTTPS. Você pode encontrar o formulário de inscrição aqui: link

A única modificação que você precisa fazer antes de enviar seu domínio é modificar seu cabeçalho para que ele armazene em cache nos navegadores por pelo menos dois anos e adicione a opção preload a ele.

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

Depois de enviar seu domínio e depois que uma nova versão do Chrome for lançada (ou qualquer outro navegador que implemente a lista de pré-carregamento HSTS do Chrome, e não necessariamente a próxima versão), seu domínio será codificado no Chrome como somente HTTPS. / p>

Pré-carregamento de HSTS para TLDs

Os proprietários de um TLD são permitidos (e incentivados) a enviar todo o seu TLD para o pré-carregamento de HSTS .

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.

E como o Google é dono do .dev TLD, eles fizeram exatamente isso. Então agora todos os *.dev domains funcionarão somente em HTTPS no Chrome. E como a maioria dos navegadores usa a mesma lista de pré-carregamento, esses navegadores também deixarão de funcionar.

Se você pesquisar a lista de domínios pré-carregados ( CUIDADO : A página está com mais de 40MB e vai demorar um pouco para renderizar. Então o seu computador pode congelar se não for poderoso o suficiente!), Você pode descobrir que os TLDs estão pré-carregados : 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 },
    
por Dan 11.12.2017 / 18:06
0

Caso você esteja fora das opções para alterar seu domínio .dev atual, é possível fazer o downgrade do seu Chrome para a versão 61 (eu fiz isso com sucesso = > aqui )

    
por Kresimir Pendic 23.02.2018 / 09:19