¿Podría HTTP-s acabar con el esiponaje de la NSA?

Tras los últimos escándalos generados por las filtraciones de Edward Snowden creo que se nos va a venir encima un montón de noticias y novedades que van a intentar provocar en los usuarios de los servicios una falsa sensación de privacidad. Dejadme que me explique, que he pasado 7 horas en un avión y no me va a ser sencillo plasmar todo esto en un artículo cortito. Comencemos por el principio.

Los escándalos de espionaje de la NSA

Ya son muchas las revelaciones que se han ido soltando en los dos últimos meses sobre las técnicas y herramientas utilizadas por la NSA (National Security Agency) americana y el GCHQ (Global Communications Headquarters). En ellas, tanto la operación Tempora como la herramienta X-Keyscore demostraban que lo que intentan hacer ambas organizaciones es capturar el tráfico de Internet en la red y analizarlo. Por supuesto, como vimos en el manual de uso de X-Keyscore, esto permite recomponer ficheros, sesiones, conversaciones de chat o correos electrónicos que hayan sido enviados por la red – que no olvidemos que siempre van sin cifrar por defecto -.

Y todo el mundo se empezó a preocupar por la privacidad un poco más, preocupándose por todo lo que podrían estar analizando.

HTTP-s: El protocolo HTTP “Seguro”

La primera de las reacciones que hemos vivido a la filtración ha sido el anuncio de Facebook de que pasa, por defecto, a funcionar en HTTP-s. Esto se ha comunicado como un avance en la privacidad y seguridad de los usuarios – que por supuesto cualquier ayuda siempre es bienvenida - pero no hay que olvidar que en la presentación filtrada uno de los ejemplos que se utilizaban eran los chats de Facebook.

Para que pueda explicarme mejor dejadme hacer una simplificación de cómo funciona el protocolo HTTP-s que está pensado para dar seguridad y privacidad a los usuarios de la web mediante dos principios básicos: Confianza y Cifrado robusto.

El cifrado robusto debería ser el menor de nuestros problemas en vista de que el punto donde más falla el sistema es en la confianza, pero digamos que salvo ataques como BEAST, CRIME o el reciente BREACH presentado este año en BlackHat USA 2013 y el uso de certificados antiguos con algoritmos débiles y claves demasiado cortas no se han encontrado “grandes problemas”. No me quiero olvidar, por supuesto, del ataque de TLS-Renegotiation de Steve Dispensa y Marsh Ray del que ya hay mucho publicado. Si quieres entender más de esto, ya sabes, a leer sobre Criptografía y RSA.

Si nos paramos en la parte de confianza… la cosa se va al garete, y más tras todo lo visto, y el control legal que Estados Unidos o China tienen sobre las grandes empresas de certificación digital, lo que les puede llevar a hacer cumplir leyes como la Patriot Act o Foreing Intelligence Survilliance Act. Para entendernos, digamos que el proceso de conseguir un canal cifrado privado pasa porque superemos un proceso de confianza, y ese proceso de confianza es difícil de sostener. Pongamos un ejemplo.

Supongamos que quiero entrar a una cuenta de servicio de Internet donde tengo mis cosas importantes – cada uno las suyas – y tengo un portal de acceso donde he de poner mis credenciales que funciona bajo HTTP-s. Para que se establezca un canal seguro y privado, primero he de confiar en que estoy conectándome al sitio que deseo y esa comprobación la hace mi sistema operativo – sea Windows, Mac OS X o iOS, por poner algún ejemplo -. ¿Cuáles son las reglas de la confianza? Pues mi sencillo:

1) Que no esté caducado
2) Que sea un certificado digital emitido para ese sitio
3) Que esté emitido por una entidad de confianza

Como os podéis imaginar, las dos primeras son bastante sencillas de superar, y el truco recae por supuesto en la tercera. Pero sigamos con el ejemplo. Para que esto funcione, el sitio al que vamos a conectarnos tiene que obtener un certificado digital emitido por una de esas entidades de confianza. Para ello va y paga a la entidad de confianza – poco si quiere uno normalito, mucho si quiere uno de validación extendida, que se ponga verde cuando el usuario navegue por ese sitio garantizando que ha habido una comprobación manual de todos los datos.

A partir de ese momento el usuario que se conecta desde su navegador al servidor recibe la parte pública de ese certificado donde comprueba que no está caducado, que está emitido para ese sitio y que está emitido por una de esas entidades de confianza.

Figura 1: Alerta con un certificado digital que no supera la confianza en Internet Explorer

La pregunta es ¿Quiénes son esas entidades de confianza? Y la respuesta es que es difícil saber el número de ellas que hay por el mundo…. Y pueden ser infinitas.

Las entidades de confianza

El sistema operativo Microsoft Windows tiene una lista de entidades de confianza cargadas por defecto, pero que además se actualizan dinámicamente, por lo que no es fácil en un determinado momento cuantificar cuántas son. Yago Jesús creo una utilidad llamada CertMon para que el sistema avise cada vez que se carga una nueva. En Mac OS X hay una lista que puedes gestionar – en alguna versión sin éxito – y en iOS no es posible dejar en una entidad de confianza marcada por Apple. Algunas herramientas, como el navegador Mozilla Firefox, decide no utilizar la lista de entidades de confianza marcadas por Microsoft o Apple, por lo que él mismo tiene un almacén de entidades de confianza en las que confía por defecto.

Figura 2: CertMon avisando de la carga de un nuevo certificado digital de confianza en Windows 7

Todas estas, son las Entidades de Certificación Raíz de Confianza. Pero no acaba aquí en quién confías.

Las entidades de confianza intermedias

Una entidad de certificación raíz de confianza, además, tiene la capacidad de emitir certificados de para entidades de certificación con la capacidad de emitir certificados digitales para cualquier sitio. Y estás, podrían a su vez crear nuevas entidades de certificación. No importa. Siempre que la raíz de los certificados sea una de las de confianza del equipo, entonces el sistema confía.

Digamos que la entidad A en la que confías emite un certificado para la entidad B (en la que no confías por defecto) y esta emite un certificado para el sitio web C, cuando tu sistema compruebe la raíz de confianza no mostrará ninguna alerta, porque tu confías en A y A ha gestionado esa confianza delegándola en B y B ha emitido el certificado del sitio C, así que tu confías.

No todos los certificados digitales pueden ser utilizados para emitir certificados, así que digamos que emitir un certificado para una entidad certificadora intermedia es un proceso restringido, pero incluso hemos visto en el pasado como creando certificados para sitio con un certificado que no era de entidad certificadora los navegadores se lo han comido como de confianza. No hay más que ver el caso de los ataques de SSLSniff.

Y todo esto es mucho peor cuando te das cuenta de que el certificado de un sitio no tiene por qué ser único.

¿Cuántos certificados que sean de confianza se pueden crear para un sitio?

La respuesta es sencilla. Infinitos. El certificado de www.google.com para que tu sistema confíe en él puede estar emitido por miles de entidades de certificación. Si recibes un certificado emitido para www.google.com de una entidad de certificación raíz de confianza tu sistema lo dará por bueno. Si lo recibes por una entidad intermedia autorizada por otra entidad intermedia que a su vez ha sido autorizada por otra entidad certificadora raíz, como confías en la raíz, confías en él y no hay problema alguno.

Habiendo tantos certificados, tu sistema puede estar dando la confianza a muchos certificados distintos de un determinado sitio, y cada vez que se da la confianza se negocian las claves de cifrado con ese servidor y ese servidor tendrá la capacidad de descifrar todo el contenido.

¿Podría la NSA o el GCHQ descifrar el tráfico si va todo en HTTP-s?

Pues claro que sí. Lo único que se necesitaría es hacer un ataque man in the middle en lugar de pinchar el cable únicamente. Ahora mismo podría estar haciéndolo, igual que lo hace China con el Great Firewall of China. Lo único que se necesita es que todas las comunicaciones cifradas se hagan con el nodo donde se intercepten las comunicaciones. Basta con que sea él, con un certificado de entidad intermedia de confianza quien emita los certificados digitales para todos los sitios de Internet a los que se visite.

El sistema del cliente confiará por provenir de una entidad de confianza raíz, y negociará todas las claves de cifrado, lo que le permitirá al nodo acceder al tráfico descifrado.

¿Cómo controlar la confianza en las entidades de certificación?

Pues no es fácil. En primer lugar hay que decir que el sistema funciona delegando la confianza en entidades de certificación en modo lista blanca, es decir, cada sistema tiene una lista de las entidades en las que confía, y si no las quiere, tiene que quitarla de la lista. Esto no es fácil en sistemas como Windows donde la lista es dinámica, por lo que habría que pedir el certificado manualmente para luego bloquearlo.

En el caso de las entidades de certificación intermedias, la única manera es que se haya creado una lista negra para cada una de ellas, pero de nuevo debes tener antes la clave pública de la entidad de certificación en tu sistema, y por supuesto ante un ataque que aún no se ha producido esto es complicado. La mejor solución para Windows para tener una aproximación al bloqueo de entidades de certificación de poca confianza es SSLCop de Yago Jesús, que permite hacer un bloqueo por países en los que confíes menos.

Figura 3: Tu sistema confía en entidades de certificación de todos estos países

En segundo lugar, si dejas de confiar en una entidad, dejas de confiar en todos los certificados que haya emitido esa entidad. Todos. Eso significa que, por ejemplo, si te cargas Verisign dejas de confiar en una cuarta parte de Internet. Moxie Marlinspike proponía hace un par de años el uso de notarios en lugar de la regla de confiar de forma transitiva.

El sistema, llamado Convergence, crea una serie de notarios que comprueban por otros canales el certificado digital del sitio al que te vas a conectar y se compara con el que tú has recibido. Si todo está okey y nadie te ha dado otro certificado que no sea el original del sitio, entonces se da por bueno. Esta idea de confiar en un único certificado y no en la raíz de confianza está siendo utilizada por muchas apps en dispositivos móviles y en plugins para navegadores. Se la conoce como Certificate Pinning y consiste en decir cuál es el certificado de un sitio web en el que confías, si hay algún cambio, que te avisen.

Sin embargo, con el negocio que hay montado y desplegado en las entidades de certificación, un sistema como Convergence con nuevos roles de menor importancia, o sistemas de Certificate Pinning donde no es necesaria una raíz de confianza hacen difícil su implantación. En SecuriByDefault tienes una reflexión sobre él.

¿Y otros sistemas de protección extra?

No voy a extenderme en otros mecanismos de protección extra, pero os dejo algunas ideas sobre ellos:

Las redes VPN: Las soluciones VPN (Virtual Private Network) son otra parte que podría ser utilizada para obtener privacidad, pero sólo vale entre tu equipo y el servidor VPN, a partir de ese momento todo lo que envíes por Internet estará sujeto a las reglas de HTTP o HTTP-s. Además, no olvides que si estás en una compañía de un país tendrá que cumplir las leyes, y no hace falta que te cuente FISA otra vez. 

La red TOR: La red TOR, dentro de la red TOR, utiliza cifrado que sólo puede romperse si hay nodos rogue metidos en ella. Visto lo que le pasó a nuestro amigo Hache, pensar que no hay nodos capturando tráfico de red para alimentar las bases de datos de los servicios de “inteligencia” es para solo los más cándidos. 

El correo electrónico: El último punto de este artículo que ya se me ha ido de las manos se lo quiero dedicar al correo electrónico, ya que por ahora, la transmisión de mensajes entre servidores de correo de organizaciones remotas va sin cifrar. Así que para alguien que pinche los cables como en Tempora o X-Keystore, será fácil leer siempre los mensajes SMTP. Se podrían utilizar soluciones como SMTP-s para el envío de mensajes entre servidores de correo o Mutual-TLS para que fueran cifrados, pero no sólo no se ha extendido ninguno, sino que además recaen en el uso de las reglas de confianza citadas anteriormente, lo mejor es que te cifres tú tus correos extremo a extremo con tu con PGP o S/MIME.

Saludos Malignos!