Chrome 63 (disponible desde Diciembre de 2017) forzará a todos los dominios terminados en .dev y .foo a ser redirigidos a través del protocolo HTTPS haciendo uso de una cabecera Preloaded HSTS “HTTP Strict Transport Security” (HSTS).
En este interesante commit en Chromium podemos observar que se añaden las cabeceras “.dev” y “.foo” a las Preload list.
Preload HSTS for the .dev gTLD.
{ "name": "dev", "include_subdomains": true, "mode": "force-https" },
{ "name": "foo", "include_subdomains": true, "mode": "force-https" }
Fuerza a todos los dominios .dev y .foo a ser redirigidos via HTTPS.
Pero… ¿existe algún gTLD .dev?
Efectivamente, existe.
Ha sido comprado por Google como uno de sus más de 100 nuevos gTLDs y aún no se sabe para que van a destinar su uso pero esto seguro que crea algo de confusión entre los desarrolladores web actuales.
Consecuencias de la redirección .dev a HTTPS
Muchos desarrolladores web usan TLDs locales .dev en sus entornos de desarrollo locales. Añadiendo una nueva fila a sus ficheros /etc/hosts o haciendo uso de otros servicios para finalmente traducir el uso *.dev en la dirección de loopback 127.0.0.1.
En eso casos, si el navegador recibe una url del tipo http://xxx.dev será redirigida la petición a la dirección https://xxx.dev, su equivalente en HTTPS.
Esto significa que la máquina de desarrollo local necesita:
- Ser capaz de atender peticiones HTTPS
- Tener certificados autofirmados
- Esos certificados autofirmados debn estar en el repositorio local de certificados válidos de nuestra máquina
¿Qué debemos hacer?
Ya que no podemos usar .dev necesitaremos cambiar nuestros entornos de desarrollo. Una buena alternativa es la de hacer uso de dominios .localhost como nuevo estándar, esto permitiría redigirir automáticamente las peticiones .localhost a la dirección 127.0.0.1 sin necesitar añadir configuración extra en nuestros ficheros /etc/hosts.
Fuente: Chrome 63 forces .dev domains to HTTPS via preloaded HSTS