Certificate pinning. El qué, el cómo y el porqué (III)

Después de aclarar conceptos en las entradas anteriores de esta serie sobre certificate pinning (las cuales puedes encontrar al final de este post) acerca de las debilidades de las PKI, el TLS/SSL en general y la solución propuesta por EMET, veamos cómo han implementado el concepto los diferentes fabricantes: es el turno de Chrome.

Chrome es el primero que se preocupó por integrar el pinning en su navegador. No es de extrañar cuando fue uno de los dominios suplantados en el conocido ataque de 2011. Además, Google es un objetivo muy goloso para cualquiera que quiera espiar comunicaciones cifradas.

Chrome usa fundamentalmente dos tecnologías diferentes que parece que se complementan. La primera es el estándar HTTP Strict Transport Security o HSTS. Se trata de una especificación que permite obligar a que, en una página, se use siempre HTTPS aunque el usuario no lo escriba en la barra del navegador. Para ello, el servidor que lo desee debe enviarle una cabecera al navegador, del tipo:

Strict-Transport-Security: max-age=16070400; includeSubDomains

Chrome (en realidad todos los navegadores populares menos Internet Explorer) entenderán que la página que envía esta cabecera quiere que se navegue por ella siempre con HTTPS (aunque el usuario no lo haya especificado) y durante el tiempo definido. Hasta aquí, no se habla de certificados, así que, ¿por qué lo unen a la funcionalidad de pinning?

HSTS y pinning

La respuesta a la pregunta anterior es la siguiente: porque esta opción de la página para ser navegada por HTTPS (lo quiera o no el usuario) la envía el servidor y se guarda en local. Se da un primer contacto del usuario al servidor en el que todavía no se ha recibido esa cabecera, esa petición no está protegida, hasta que se reciba la respuesta y la recuerde el navegador. ¿Y si un atacante ya controla la red desde esa primera solicitud sin HTTPS, intercepta esa primera petición y desvía el tráfico o elimina la cabecera? Siempre habrá una ventana de tiempo inicial en la que un ataque es posible.

Así que Chrome ha incorporado en su código fuente páginas que siempre funcionarán con HTTPS activo, desde el principio: “Preloaded HSTS sites” las llama. Esa lista se comparte con Firefox y cualquier dominio puede solicitar que se le incluya en el código fuente como “precargado con HSTS”, enviando un email a alg@chromium.com. Ya hay muchos (se ve en el código fuente).

Con esto se consigue que, nada más arrancar Chrome, se vaya al dominio HTTPS de la página, y a partir de ahí (que se supone que es el sitio autenticado) continuar. Esto también es una especie de pinning. Si el dominio lo desea, puede dejar de enviar la cabecera en cualquier momento, y el navegador ya no obligará al uso de HTTPS. Este sistema es interesante, pero el hecho de utilizar el código fuente como “repositorio” de páginas que quieren usar “HSTS precargado” desde el primer momento no parece muy sostenible a largo plazo.

¿Están cubiertos todos los flancos?

Ahora bien, sigue existiendo un punto débil. ¿Y si, aunque siempre se contacte desde el primer momento con estos dominios con HSTS (y por tanto con SSL activo) en una red muy hostil, ya se ha producido el ataque MiTM y se le redirige a una web cifrada diferente? Puede ocurrir que se la víctima visite un dominio HSTS preinstalado, pero pase por una red donde la cadena de certificación sea válida pero no la original (se le esté espiando)…

¿Y si cuando el navegador acude obligatoriamente al dominio autenticado, la autenticación no es real porque se están usando certificados intermedios diferentes o se han emitido falsos? Ahí entra el certificate pinning propiamente dicho. El navegador, además de exigir SSL desde el primer momento, independientemente de que el usuario escriba HTTPS en la barra de direcciones, recordará qué claves públicas le son reconocidas y rechazará el resto. ¿Cómo funciona todo esto en la práctica? Veremos algunos ejemplos técnicos de cómo funciona el “pinneo” de Chrome en la siguiente entrega: