Chrome: el sitio web utiliza HSTS. Errores de red ... esta página probablemente funcionará más tarde

162

Estoy desarrollando contra localhost. Esta mañana, justo después de usar Fiddler, comencé a recibir este error en Chrome (funciona correctamente en Firefox)

"No puede visitar localhost en este momento porque el sitio web usa HSTS. Los errores y ataques de red suelen ser temporales, por lo que esta página probablemente funcionará más tarde". ingrese la descripción de la imagen aquí

Ahora localhost funciona en Chrome solo si se está ejecutando Fiddler. Ya me aseguré de que las redirecciones de proxy que realiza el violinista se corrijan cuando el violinista se apaga.

También intenté importar el certificado a mi raíz de confianza y reiniciar el navegador (y también la máquina).

desarrollador747
fuente
2
Me encuentro con este problema cuando el administrador de TI cambia sus políticas. Todo lo que necesito hacer es ejecutar el comando: gpupdate / force
Jacob Phan

Respuestas:

192

Una forma muy rápida de evitar esto es cuando estás viendo la pantalla "Tu conexión no es privada":

tipo badidea

tipo thisisunsafe(crédito a The Java Guy por encontrar la nueva frase de contraseña)

Eso permitirá la excepción de seguridad cuando Chrome no permita que la excepción se establezca mediante clics, por ejemplo, para este caso HSTS.

Obviamente, esto solo se recomienda para conexiones locales y máquinas virtuales de red local, pero tiene la ventaja de funcionar para máquinas virtuales que se utilizan para el desarrollo (por ejemplo, en conexiones locales enviadas por puerto) y no solo para conexiones locales de host local.

Nota: los desarrolladores de Chrome han cambiado esta frase de contraseña en el pasado y pueden volver a hacerlo. Si badideadeja de funcionar, deje una nota aquí si aprende la nueva frase de contraseña. Intentaré hacer lo mismo.

Editar: a partir del 30 de enero de 2018, esta frase de contraseña parece que ya no funciona.

Si puedo cazar uno nuevo, lo publicaré aquí. Mientras tanto, me tomaré el tiempo para configurar un certificado autofirmado utilizando el método descrito en esta publicación de stackoverflow:

¿Cómo crear un certificado autofirmado con openssl?

Editar: a partir del 1 de marzo de 2018 y la versión de Chrome 64.0.3282.186, esta frase de contraseña vuelve a funcionar para los bloques relacionados con HSTS en los sitios .dev.

Editar: a partir del 9 de marzo de 2018 y la versión 65.0.3325.146 de Chrome, la badideafrase de contraseña ya no funciona.

Edición 2: el problema con los certificados autofirmados parece ser que, con los estándares de seguridad más estrictos en estos días, provocan que se arrojen sus propios errores (nginx, por ejemplo, se niega a cargar un certificado SSL / TLS que incluye un certificado autofirmado en la cadena de autoridad, por defecto).

La solución con la que voy ahora es cambiar el dominio de nivel superior en todos mis sitios de desarrollo .app y .dev con .test o .localhost. Chrome y Safari ya no aceptarán conexiones inseguras a dominios de nivel superior estándar (incluido .app).

La lista actual de dominios de nivel superior estándar se puede encontrar en este artículo de Wikipedia, incluidos los dominios de uso especial:

Wikipedia: Lista de dominios de nivel superior de Internet: dominios de uso especial

Estos dominios de nivel superior parecen estar exentos de las nuevas restricciones solo https:

  • .local
  • .localhost
  • .prueba
  • (cualquier dominio de nivel superior personalizado / no estándar)

Consulte la respuesta y el enlace de codinghands a la pregunta original para obtener más información:

respuesta de codinghands

Rick Gladwin
fuente
19
Nunca he oído hablar de algo así, pero por alguna razón funciona. ¡Gracias!
Alexey
ayuda masiva! Muchas gracias!
RHSmith159
Ni siquiera puedo creer que esto funcione pero funciona. No estoy seguro de si debería estar feliz o enojado porque esto no está documentado; He pasado HORAS a lo largo de los años lidiando con esta basura en entornos de desarrollo.
Scott Byers
77
Utilice thisisunsafeinsread de badidea. Esto ha cambiado con la nueva versión
The Java Guy
funciona +1, sin embargo, Chrome realmente debería agregar una opción para continuar con las advertencias, en lugar de simplemente bloquear
5413668060
186

Cuando visitó https: // localhost anteriormente en algún momento, no solo lo visitó a través de un canal seguro (https en lugar de http), también le dijo a su navegador, usando un encabezado HTTP especial: Strict-Transport-Security (a menudo abreviado como HSTS ), que SOLO debe usar https para todas las visitas futuras.

Esta es una característica de seguridad que los servidores web pueden usar para evitar que las personas sean degradadas a http (ya sea intencionalmente o por alguna parte malvada).

Sin embargo, si luego apaga su servidor https y solo quiere navegar por http, no puede hacerlo (por diseño, ese es el punto de esta característica de seguridad).

HSTS también evita que acepte y saltee errores de certificados anteriores.

Para restablecer esto, para que HSTS ya no esté configurado para localhost, escriba lo siguiente en su barra de direcciones de Chrome:

chrome://net-internals/#hsts

Donde podrá eliminar esta configuración para "localhost".

¡Es posible que también desee saber qué estaba configurando esto para evitar este problema en el futuro!

Tenga en cuenta que para otros sitios (por ejemplo, www.google.com) estos están "precargados" en el código de Chrome y, por lo tanto, no se pueden eliminar. Cuando los consulta en chrome: // net-internals / # hsts los verá listados como staticentradas HSTS.

Y finalmente tenga en cuenta que Google ha comenzado a precargar HSTS para todo el dominio .dev: https://ma.ttias.be/chrome-force-dev-domains-https-via-preloaded-hsts/

Barry Pollard
fuente
Estoy obteniendo esto para gmail.com. Fui a chrome: // net-internals / # hsts y pregunté gmail.com, obtuve Found: static_sts_domain: gmail.com static_upgrade_mode: STRICT Intenté eliminar el dominio, pero todavía tengo el problema.
paiego
Esta respuesta tiene sentido para mí. Sin embargo, mi problema es que cambié el servidor de nombres de un sitio web de wordpress (alojado en wordpress) a mi servidor (alojado automáticamente) y ahora obtengo esto y presumiblemente también lo harán todos los visitantes de Chrome. ¿Alguna idea de cómo evitarlo para los visitantes sin que eliminen su caché?
TomC
2
Básicamente, la única respuesta es usar HTTPS en el futuro o esperar que los usuarios no lo tengan en caché. HTTPS es el camino a seguir y libre de LetsEncrypt. También debe verificar si alguien ha precargado su sitio en el código de los navegadores, pero adivine si puede restablecerlo usted mismo. No estoy al tanto de que Wordpress agrega HSTS automáticamente, así que pregúntate cómo llegó eso allí.
Barry Pollard
Gracias @BazzaDP, no puedo evitar esto. Es posible que deba volver a cambiar los servidores de nombres, averiguar qué en el sitio anterior estaba forzando HTTPS y luego intentar migrar nuevamente. No puede simplemente FTP desde los blogs alojados en Wordpress al nuevo sitio, por eso esto es un problema para mí y el nuevo propietario del sitio no tiene un certificado SSL (aunque considera seriamente obtener uno de todos modos)
TomC
2
Como mencioné en mi respuesta, las entradas precargadas (o STS estáticas) no se pueden eliminar ya que existen en el código de Chrome y no en una lista mantenida localmente. Y según mi última línea en mi respuesta, Google ha decidido precargar todo el dominio de desarrollo.
Barry Pollard
24

Haga clic en cualquier lugar de la ventana de Chrome y escriba thisisunsafe(en lugar de badideaanteriormente) en Chrome.

Esta frase de contraseña puede cambiar en el futuro. Esta es la fuente

https://chromium.googlesource.com/chromium/src/+/master/components/security_interstitials/core/browser/resources/interstitial_large.js#19

De acuerdo con esa línea, escriba window.atob('dGhpc2lzdW5zYWZl')en la consola de su navegador y le dará la frase de contraseña real.

Esta vez la frase de contraseña es thisisunsafe.

El chico java
fuente
19

Tuve este problema con los sitios que se ejecutan en XAMPP con nombres de host privados. ¡No es tan privado, resulta! Eran todos domain.dev, que Google ahora ha registrado como un gTLD privado , y está obligando a HSTS a nivel de dominio. Cambió cada host virtual a .devel(eugh), reinició Apache y ahora todo está bien.

codinghands
fuente
Puedo confirmar este problema con Opera 50.0.2762.9 y que el cambio de mi dominio del desarrollo .devde .devellas obras alrededor de la restricción.
Courtney Miles el
55
RFC 2606 reserva algunos dominios de nivel superior específicamente para evitar conflictos con las pruebas privadas. Parece que .testes quizás el más correcto para cambiar a entornos de desarrollo.
Courtney Miles el
Esto literalmente me salvó la vida después de días de no poder entender por qué Chrome estaba actuando así en mi .devdominio localhost ... Dios, quién sabría ...
D. Petrov
Bueno, en realidad .test solo se recomienda para usar en pruebas de código relacionado con DNS actual o nuevo.
Alexey
Esto aquí ha resuelto mi problema. Estoy usando Laragon para mi entorno de desarrollo.
Craig
12

Recientemente tuve el mismo problema al tratar de dominios de acceso utilizando CloudFlare Origen CA .

La única forma en que encontré para solucionar / evitar la excepción del certificado HSTS en Chrome (compilación de Windows) fue siguiendo las breves instrucciones en https://support.opendns.com/entries/66657664 .

La solución alternativa:
agregue a Chrome el acceso directo a la bandera --ignore-certificate-errors, luego vuelva a abrirla y navegue a su sitio web.

Recordatorio:
Úselo solo para fines de desarrollo.

ingrese la descripción de la imagen aquí

Binyamin
fuente
Tal vez intente en Google Canary construir google.com/chrome/browser/canary.html
Binyamin
Suponga que no tiene un sitio que causa un error de certificación. Entonces, ¿cómo verificaría si su solución funciona? No ayuda aquí - stackoverflow.com/questions/41902367/…
MasterJoe2
¿Qué hay de las versiones de Mac?
The Java Guy
2

Me encuentro con el mismo error, y el modo de incógnito también tiene el mismo problema. Resuelvo este problema borrando el historial de Chrome.

wangf
fuente
2

He sufrido este problema por mucho tiempo. No pude abrir sitios web como GitHub. Casi probé todas las respuestas en la web y nadie trabajó. Intenté reinstalar Chrome también. Encontré la solución para esto de nuestro chico de la red y funcionó. Hay una solución en el registro que resolverá este error de forma permanente.

  1. Presione la tecla Windows + R para abrir el cuadro de diálogo Ejecutar
  2. escriba: regedit y presione enter para abrir el registro
  3. En la vista de árbol a la izquierda, haga clic en la siguiente ruta HKEY_LOCAL_MACHINE> SOFTWARE> POLÍTICAS> Microsoft> SystemCertificate> Authroot
  4. Ahora haga doble clic en DisableRootAutoUpdate a la derecha y configúrelo en 0 (cero) en el cuadro de diálogo que aparece
  5. Reinicie su PC para aplicar cambios en el registro y ya no recibirá este error

La solución anterior es para Windows 8. Es casi idéntica en versiones posteriores, pero no estoy seguro de versiones anteriores como XP y vista. Entonces eso necesita ser verificado.

Maulik Modi
fuente
¿Sabes lo que significa esta opción?
MasterJoe2
@ testerjoe2: No señor
Maulik Modi
1
Estaba sufriendo este google-analytics.com junto con varios otros dominios de google. Esta respuesta resolvió mi problema.
Shawn
El artículo en support.microsoft.com/en-us/help/2813430/… explica el comportamiento de las claves que se introdujeron en un parche para Windows Vista. Establecer este valor particular en 0 hace que los certificados raíz actualizados se obtengan automáticamente de Windows Update y se instalen en el almacén de las Autoridades de certificación raíz de confianza. En un entorno empresarial, esto puede desactivarse como medida de seguridad; sin embargo, eso significa que alguien debe administrar Autoridades de certificación raíz de confianza a nivel empresarial.
JamieVer