Empecé a hablar de HTTPs ya por el 2012, cuando algunos de los grandes servicios de Internet se animaron a dar el paso.
Y tuvieron que pasar dos añitos para que ese movimiento fuera abrazado como un estándar… forzado de la mano de Google. Un estándar qué, recordemos, conllevaba un coste de mantenimiento anual de alrededor de 100 euros por dominio, y que por tanto ni de lejos parecía estar cerca de producirse de forma masiva.
Sin embargo, en apenas unos meses lo que hasta el momento tenía un coste de mantenimiento anual para cualquier administrador de sistemas (sin olvidar el coste de implementación, que sigue siendo el mismo) pasó a ser gratis. O al menos, con la llegada de plataformas como Let’s Encrypt, se abrió esta posibilidad.
De pronto cualquiera podía firmar sus conexiones como cifradas de punto a punto sin tener que pasar por una certificadora oficial (y por tanto pagar por la certificación). Algo que a varios años vista ha creado un escenario en el que cada vez más servicios digitales cargan por defecto por HTTPs (aún nos queda camino por recorrer a nivel de páginas corporativas, sobre todo de PYMES), y de paso, ha abierto la Caja de Pandora a un problema hasta el momento desconocido:
El “candadito” de la barra de direcciones, que históricamente hemos asociado a una página segura, privada y legítima, ya solo define lo segundo.
Que aún me llevo las manos a la cabeza cuando a oigo a gente del sector recomendar como medida de seguridad de cara a saber si una página es la real o un phishing que se fijen en si tiene un candadito en la barra de direcciones.
Con la llegada de Let’s Encrypt y la democratización de las conexiones HTTPs hemos ganado, en efecto, en privacidad. Pero se han perdido los controles de legitimidad que sí ofrecían (con algunos fallos, por supuesto) las certificadoras de SSL, por lo que ya no es raro encontrarse ante páginas de phishing/fraude que tienen el candadito de marras.
El que Google (y por ende, el resto de la industria) haya jugado con la misma señalética este cambio de conexiones no cifradas a cifradas también ha complicado el paulatino aprendizaje de la ciudadanía sobre estos temas. Que en español “Secure” y “Security” se traduzcan ambos como “Seguridad” pese a que en el idioma de Shakespeare ambas palabras definen conceptos diferentes, tampoco ayuda.
Afortunadamente desde hace unos meses hemos pasado a considerar el HTTPs la conexión por defecto (el candadito en el mismo color que la tipografía, y ya no resaltado en verde como hasta entonces), y la barra de navegación solo nos alerta cuando la página no tiene HTTPs (muestra un “No seguro” en rojo, que más bien debería ser un “No privada”, pero que al menos ya es un mal menor).
Y el que una web que cargue mediante HTTPs sea un criterio más a considerar de cara al posicionamiento de la misma ha ayudado a que muchos negocios tomen acción y contraten a profesionales como un servidor para ayudarles con la migración… pese a que les de exactamente igual la privacidad de sus usuarios (una jugada maestra de los de Mountain View).
El siguiente paso, por tanto, era hacer algo con lo que en el mundillo llamamos el contenido mixto.
Y es justo lo que Chrome anunciaba hace apenas unos días.
Chrome bloqueará por defecto las imágenes, vídeos y audios que no carguen por HTTPs
Los chicos del buscador por antonomasia del momento han dado a conocer la semana pasada el roadmap para eliminar el contenido mixto de Internet (EN).
Es decir, ese contenido que se enlaza mediante HTTP en una web que ya carga por HTTPs, y un problema muy habitual que nos encontramos los que estamos al otro lado implementando esto en diferentes páginas.
Puede que tu web ya esté preparada y bien migrada a HTTPs, pero si alguna página enlaza a un contenido de terceros que carga forzosamente por HTTP, en la práctica aunque la conexión que haga el usuario con tu web sea cifrada, se está vulnerando su privacidad por ese elemento, cuya petición, al no ser cifrada, se hace en texto plano.
Para atajarlo el plan de Google es hacer un bloqueo progresivo a través de varias versiones del navegador.
- En Chrome 79, que llegará en diciembre de este mismo año, se añadirá una opción en el panel de información del HTTPs (haciendo click sobre el candadito como puedes ver en la imagen superior) para que sea el usuario quien decida qué hacer con el contenido mixto.
- En Chrome 80, que se espera para el primer trimestre de 2020, todo recurso de audio y vídeo que no cargue por HTTPs se le forzará a que lo haga. Y si no es posible, por defecto se bloqueará. Si el contenido HTTP es una imagen y no es posible cargarla mediante HTTPs Chrome permitirá su visionado pero marcará esa página como “No segura”.
- Para Chrome 81 todo contenido que no pueda cargar mediante HTTPs se bloqueará por defecto.
El pasito final para que en efecto las conexiones que hagamos desde nuestros dispositivos sean sí o sí seguras en conexiones HTTPs.
Queda por ver cómo arderá Troya cuando dentro de uno o dos años por defecto toda web que aún cargue por HTTP sea bloqueada.
Una evolución natural del escenario digital que no está exenta de problemas, como ya comentamos en su día.
