Cada vez se descubren más problemas en la infraestructura de seguridad de Internet.
Como decíamos en otras notas, gran parte de la infraestructura de Internet fue desarrollada para que sea centralizada. Muchas somos clientes, unas pocas son servidores. Unas almacenan la gran mayoría de los datos que circulan por Internet, nosotras los producimos.
Una de esas infraestructuras centralizadas es la que implementa el protocolo x509, que es el que utilizan por ejemplo, todos los sitios seguros: desde el home banking hasta Facebook (con suerte). Cuando vemos que el navegador nos muestra la dirección del sitio con un candadito, un ícono verde o comienza con «https», sabemos que la conexión es segura. En teoría, nada ni nadie puede saber qué estamos transmitiendo, sólo nosotras y el sitio con el que nos estamos conectando. Ni siquiera el firewall del lugar donde trabajemos. Por eso, si un sitio ofrece la posibilidad de conectarse de forma segura, siempre tenemos que optar por esto.
Una forma de hacerlo automáticamente (es decir, sin tener que preocuparnos) durante la navegación web, es instalar en los navegadores Mozilla (Firefox, IceWeasel, GNU IceCat, etc.) la extensión HTTPS Everywhere de la Electronic Frontier Foundation. Esta extensión configura el navegador para visitar siempre la versión segura de un sitio. No necesita configuración manual, sólo funciona.
Otros programas, como los clientes de correo o de chat, también permiten este tipo de conexiones y nos dan la opción de habilitarlo. Incluso algunas proveedoras, como riseup no soportan otro tipo de conexiones que no sean seguras.
Si bien este tipo de infraestructura permite un alto grado de seguridad y privacidad en nuestras comunicaciones sobre Internet, posee algunos problemas que comienzan a ser graves y que provienen de su diseño centralizado.
Funcionan de la siguiente manera: para que una conexión sea segura, el servidor al que nos queremos conectar tiene que tener un «certificado». Este certificado indica entre otras cosas que el dominio y la dirección del servidor son correctas, de forma que el navegador pueda comprobar si el servidor que nos dio ese certificado es válido. ¿Pero cómo podemos saber si el certificado en sí es válido? Una opción es comprobarlo a mano: cada vez que nos conectamos al home banking, comprobamos que el certificado sea el mismo que el banco dice que tiene (podrían imprimirlo en la tarjeta como una serie de letras y números, por ejemplo). Pero la forma que prescribe esta infraestructura de seguridad es a través de «autoridades certificantes» o CAs.
Las CAs son entidades, generalmente corporativas, que otorgan certificados a los sitios. De esta forma, una sola CA puede entregar miles de certificados. Si confiamos en el certificado de la CA, confiamos automáticamente en todos los sitios que le hayan comprado un certificado.
Esto es lo que pasa regularmente. Cuando instalamos un navegador, viene de fábrica con una serie de certificados, que pertenecen a cada CA. Cuando entramos a un sitio seguro, el navegador comprueba que el certificado pertenezca al sitio con el que nos conectamos y a la vez comprueba si, según la CA, el certificado es válido.
¿Cuáles son los problemas? Por ejemplo, si la CA tuviera un problema de seguridad, como le pasó al Comodo Group en 2011, cualquiera con acceso a sus claves podría generar certificados válidos para sitios falsos: podemos entrar a un home banking que es igual al original, pero le estamos dando nuestros datos a terceras. No obstante, esto es un ejemplo individual. Los estados y las agencias de espionaje tienen interés en generar sitios seguros pero falsos con el objetivo de monitorear la actividad de la población de todo un país (o de todo el mundo).
Esto fue hecho no sólo por la NSA.Hace un tiempo, Google descubrió que alguien había querido falsificar los certificados de sus sitios en Francia. El gobierno francés tuvo que admitir que no era su intención que Google descubriera que estaban intentando monitorear a sus usuarias.
El otro problema es que los certificados, si bien en la práctica son archivos bastante livianos, salen caros (unos u$d 200) y se renuevan anualmente. Esto hace que muchos sitios opten por no dar seguridad a sus usuarias y nuestros datos puedan ser monitoreados sin más, ya que la información viajaría por la red en lo que se conoce como «texto plano», es decir, perfectamente legible y analizable a simple vista.
La falla en el diseño de x509 es precisamente su centralización, que produce una escasez artificial de privacidad y seguridad, además de una falsa apariencia de seguridad.
¿Qué podemos hacer? Las más paranoicas optan por eliminar los certificados de las CA y realizar el proceso de validación a mano. No es tan complejo como suena, pero siendo que los certificados se renuevan anualmente, puede llegar a ser engorroso.
Existen diversos proyectos que intentan solucionar algunos de estos problemas de forma automática. Uno de ellos es HTTPS Everywhere, que ya mencionamos. El otro es Perspectives. Lo que hace Perspectives es agregar la figura de la «notaria», para reemplazar a la autoridad certificante (verán que la terminología se asemeja a estructuras verticalistas humanas). Al conectarse a un sitio seguro, Perspectives le pregunta a varios servidores que actúan de notarias si conocen ese certificado. Si están de acuerdo en que ese certificado es correcto, entramos al sitio. Si el certificado es falso, Perspectives nos muestra un error y nos avisa que el sitio puede ser falso.
La otra solución es empezar a pedirles a los sitios que utilizamos regularmente, que empiecen a ofrecer la opción de conexión segura en sus servidores.
La combinación de estas dos extensiones para los navegadores Mozilla resulta muy útil para empezar a resolver el problema de la seguridad centralizada.
