Solo lectura

Google Chrome - Foro de ayuda

Esta página web es un archivo de los hilos antiguos de los foros de Google. Más información

Los dominios .app, .dev, etc. solo se pueden usar con HTTPS

avm99963
28/12/17 9:49

Desde la versión 63 de Chrome, las páginas web de los dominios .dev, .foo, .page, .app o .chrome solo se podrán visitar a través de HTTPS y no HTTP.[1] En este hilo intentaré explicaros brevemente el por qué de este cambio, cómo solucionar posibles problemas que puedan surgir, y al final pondré una serie de preguntas frecuentes sobre este tema.[2]


Un poco de historia: ¿cómo hemos llegado hasta aquí?

Alrededor de finales del 2014 Google aplicó para ser la entidad que registra los dominios anteriormente mencionados. Esos dominios, según la aplicación que envió Google, estarían reservados para páginas web exclusivas de Google.[3]


La cuestión es que en septiembre Google anunció que iba a añadir algunos dominios, empezando por .dev y .foo, a la lista de sitios HSTS precargada. Esta es una lista que viene con el navegador y que contiene una serie de páginas web (y desde hace poco también dominios enteros) que deberían cargarse únicamente mediante el protocolo HTTPS (y no mediante HTTP). Esta decisión, según Google, se hizo porque al añadir esos dominios a la lista, todas las páginas web de esos dominios no se podrían cargar mediante HTTP, que es un protocolo muy inseguro, sino siempre por HTTPS, que es seguro. Es decir, esta decisión comportaba que esos dominios se convirtieran en seguros de facto. Pero esto ha traído un poco de polémica.


Para empezar, esta decisión podría parecer razonable: Google es el "propietario" de esos dominios, así que está bien que quiera que todos ellos sean seguros de facto. Pero lo que ocurre es que algunos programadores o webmasters hospedan desde hace tiempo localmente (o internamente en una red) páginas web usando los dominios mencionados anteriormente. Esto lo hacen editando un archivo llamado HOSTS,[4] que básicamente sirve para definir manualmente dónde encontrar páginas web. Así, editando este archivo se puede hacer que al visitar una página como http://pagina.dev se cargue el contenido de la página web hospedada en su mismo ordenador en vez de ir a buscar el contenido de esa página web a Internet (esto está explicado en términos demasiado sencillos, en realidad no es exactamente así).


¿Qué ocurre? Los programadores que usaban dominios como pagina.dev tal como he explicado anteriormente, acaban de ver que sus páginas web ya no cargan correctamente. En vez de eso, se les redirige a la página con el protocolo HTTPS (en el ejemplo sería https://pagina.dev), y por lo tanto no les carga. La causa es clara: es porque se ha añadido el dominio .dev (y otros más) a la lista de sitios HSTS precargada. ¿Pero qué puede hacer ahora el programador para solucionar este problema?


Soluciones para el problema

Actualmente existen varias soluciones para este problema. Dependiendo de la situación, puede ser más sencillo optar por una u otra:


Solución 1: cambiar el dominio de la página web

Esta a priori sería la situación más sencilla. Se debería cambiar el archivo HOSTS para que en vez de cargar la página mediante un dominio que se ha añadido a la lista de sitios HSTS precargada, se cargue mediante un dominio que acabe con .test. Los dominios .test están reservados para ser usados localmente,[5] así que no habrá peligro de que en el futuro ocurra algo similar a lo que ha ocurrido actualmente con estos dominios.


Lo que ocurre es que puede que se haga referencia al dominio en el código fuente de la página, así que posiblemente se deberán cambiar todas estas referencias por el nuevo dominio .test.


Solución 2: configurar un certificado HTTPS manteniendo el mismo dominio

Alternativamente, se puede configurar un certificado HTTPS para usarlo con el dominio que se está usando. El procedimiento sería el siguiente: generar un certificado, configurarlo correctamente en el servidor web que se use localmente, y finalmente añadir el certificado a la lista de certificados confiados por Chrome. Dependiendo del sistema operativo, servidor web y otras variables, las instrucciones son unas u otras, así que si se opta por esta solución se podría buscar en Internet algo como [certificado ssl local apache linux] (en este caso pondría esto porque tengo Apache como servidor y Linux como S.O).


Esta solución sería las más idónea o sencilla si hay demasiadas referencias al dominio dentro del código fuente. Aun así, no es recomendado usar esta solución porque se sigue usando un espacio de dominios que está siendo usado por Internet y no está reservado para uso local.


Preguntas frecuentes (FAQs)

P: ¿Si me cambio a otro navegador solucionaré este problema?

R: Por el momento algunos navegadores no han incorporado estos dominios a sus listas HSTS, pero en una actualización muy cercana seguramente tendrán el mismo comportamiento que Chrome porque estos navegadores usan una lista basada en la lista HSTS de Chrome.[6]


Se irán incorporando más preguntas en la sección de preguntas frecuentes a medida que se vayan preguntando en el Foro, en el caso que sean relevantes.


[1]: Google Online Security Blog: Broadening HSTS to secure more of the Web (en inglés)

[2]: Información obtenida de https://icannwiki.org (en inglés)

[3]: Use a .dev domain? Not anymore. – Medium Engineering (en inglés)

[4]: Archivo hosts - Wikipedia, la enciclopedia libre

[5]: RFC 2606 - Reserved Top Level DNS Names

[6]: HSTS Preload List Submission

Respuestas (1)

alvaro_argentina
28/12/17 17:04
gracias por la informacion es muy util, que bueno que hace rato pase todo a https pero muy util info