Facebook cambia la lógica en su política TLS (en parte por nuestro estudio) implementando un HSTS “en ambas direcciones”

lunes, 30 de abril de 2018

Facebook y privacidad. El reciente escándalo de la red social en las últimas semanas no la convierte en el mejor ejemplo precisamente para hablar de privacidad o conexiones seguras en general. Pero ese no es el asunto ahora. Lo cierto es que ha sido la primera web (o más bien, "plataforma") en dar un paso muy interesante e innovador en la política de renovación TLS que está viendo Internet en los últimos años, que implica el refuerzo del concepto TLS en general desde todos frentes: "TLS Everywhere", certificados accesibles o gratuitos, HSTS, Certificate pinning, Certificate Transparency, dar de lado a protocolos antiguos... una profunda revisión del ecosistema a la que Facebook (e Instagram) se unen con una propuesta más que interesante.

Ya sabéis de qué va HSTS... el servidor envía una cabecera al navegador para que recuerde que la redirección de HTTP a HTTPS debe hacerse "en local" (a través de un redirect de tipo 307), omitiendo el peligro de un secuestro en la red. La web que ofrece esta cabecera, debe, obviamente, estar disponible por HTTPS, y garantizar un mínimo de buenas prácticas con la autenticación y cifrado que ofrece el TLS. Hasta ahí, estupendo, digamos que alguna que otra vez hemos hablado del asunto, pero, ¿y si le damos la vuelta a la tortilla? Esta es lo que pensaron desde Facebook, y acaban con un concepto más que interesante para mejorar la seguridad global, que quizás sea imitado por otras plataformas.

HSTS tiene algunos huecos
En su blog de seguridad oficial, Facebook anunciaba hace algunas semanas una actualización a la seguridad de los enlaces en Facebook. ¿En qué consistía? En la entrada de Jon Millican (ingeniero del equipo de privacidad de datos en Facebook) introducía el concepto de HSTS y a continuación, anunciaba una serie de puntos débiles conocidos (vienen de serie con el mecanismo, prácticamente) de HSTS, que iban a intentar cubrir con esta nueva aproximación. Veamos:
  • No todos los navegadores soportan HSTS: Cierto, aunque sí la inmensa mayoría. Es un argumento no muy fuerte, pero que sí suma.
  • El preload no es tan dinámico. Cierto. El preload viene a cubrir ese hueco de "TOFU" (confiar en el primer uso) que es el talón de Aquiles de HSTS. Esa primera conexión con un sitio que se realiza en texto claro porque todavía no ha enviado la primera cabecera HSTS. Esta lista de "preload" está incrustada en los navegadores, y es cierto que no resulta por tanto tan dinámica como debería. La gestiona Google, pero muchos la consumen y se actualiza con las versiones del navegador.
  • No todos los navegadores implementan como deberían el HSTS. Y aquí referencian a nuestro estudio presentado en Black Hat Europa 2017 que demostró que Chrome, Firefox e Internet Explorer gestionan de manera "cuestionable" HSTS y HPKP y que supone un problema que también intentan resolver con su propuesta.
Facebook menciona nuestro estudio como una parte de su argumentario para implementar esta mejora

Con estos argumentos en las manos, proponen una solución desde su lado. ¿Y si son ellos desde su todopoderosa posición, los que añaden la "S" a HTTPS a todo enlace a otro lugar en Facebook e Instagram?

HSTS... en ambas direcciones
Mucha gente "vive" en esas webs, y cuando visita algo, sale de ahí hacia otro dominio pinchando en enlaces que Facebook "aloja". Su idea precisamente es que Facebook añada la "S" al protocolo, aunque el usuario que la escribió y enlazó no lo hubiera hecho. Así que lo que han decidido es:
  • Todo dominio que se presente en Facebook e Isntagram para ser "pinchado" por un usuario, y además se encuentre en la lista de "preload" oficial de Google, se le añadirá la "S" para que sea navegado de forma segura. Así cubren a potenciales usurarios con su lista desactualizada o que usen un navegador que no lo soporte.
  • Ellos por su cuenta "crawlearán" la web en general en busca de sitios que ofrezcan HSTS. Si están seguros de ser fiables (no sabemos cómo) añadirán más y más dominios a su lista cada vez para agregarles desde sus propios servidores, la "S" y que los usuarios que lo pinchen no dependan de su navegador para beneficiarse de un HSTS desde la plataforma Facebook.
En resumen, un HSTS inverso que viene a complementar potenciales lagunas del mecanismo, y que deberían quizás imitar otros por su sencillez en relación con sus potenciales ventajas. Trabajar desde el punto de vista de una plataforma puramente en el servidor, resulta algo quizás intrusivo pero útil en el contexto Facebook e Instagram, por el diverso perfil de sus usuarios y su popularidad. Esta loable iniciativa se empañó, poco después de su anuncio, por el escándalo de Cambridge Analytics.

HSTS... para todos
Con respecto a cubrir huecos que puediera dejar el HSTS, no olvidemos que Google ya dio un paso muy interesante en este sentido. Google, además de todo lo que ya sabemos, es también un registrador de dominios de primer nivel... como por ejemplo:.gle, .prod, .docs, .cal, .soy, .how, .chrome, .ads, .mov, .youtube, .channel, .nexus, .goog, .boo, .dad, .drive, .hangout, .new, .eat, .app, .moto, .ing, .meme, .here... y así hasta 45. En octubre anunció que cargará en la lista de preload por defecto a todo el que registre un dominio en ellos. Esto quiere decir en la práctica que les obliga a que implementen TLS desde el primer momento puesto que Chrome les accederá por el puerto 443 quieran o no.

Para rematar, no olvidemos que este año Google también quiere tachar de "no seguro" ya directamente (por ahora con las palabras "No seguro" en la barra de direcciones, pero el aspa roja en Chrome llegará), cualquier cosa por HTTP. Un auténtico acoso y derribo al tráfico no cifrado. Y una oportunidad para los creadores de certificados y CAs...

Al final, cualquier cosa con HTTP será marcada como no segura


Nuevas versiones de PinPatrol

Por cierto, hablando de HSTS... tenemos nuevas versiones de PinPatrol para Chrome y Firefox, con las que se puede controlar mejor las entradas HSTS y HPKP de los navegadores, con mejoras de usabilidad y compatibilidad.

Sergio de los Santos
ssantos@11paths.com
Innovación y laboratorio
@ssantosv

No hay comentarios:

Publicar un comentario