Investigadores consiguen hacer que cualquier certificado SSL parezca válido

Antes de que termine este año de catástrofes en la Red, un grupo de investigadores consiguen asestar otro golpe a una de las infraestructuras de Internet en la que se confía: la PKI (infraestructura de claves públicas). Aunque el impacto real será mínimo, se ha conseguido demostrar empíricamente que es posible falsificar cualquier certificado SSL y por tanto, que los navegadores den como válidos certificados falsos que harían aparecer páginas fraudulentas como legítimas.

Esta es una de esas noticias que se presta a cierta exageración en los medios, al igual que pasó con la supuesta ruptura del WPA con TKIP o con el ataque sockstress, ambas de solo hace unas semanas. En realidad solo se ha demostrado algo que se suponía teórico (que no es poco). El SSL no está roto, el problema real reside en cómo lo utilizan algunas autoridades certificadoras “anticuadas”, o sea, en un modelo de PKI concreto. Por último, destacar que el hecho de que los investigadores hayan usado la potencia de 200 consolas PlayStation3 para conseguir su objetivo, es irrelevante, solo desvía la atención del problema aunque añada cierto “glamour”.

En realidad, las raíces reales del problema son dos: las conocidas colisiones del algoritmo MD5, y que ciertas autoridades certificadores todavía lo usen. Vamos a realizar una pequeña introducción sobre los certificados y luego explicar cómo lo han conseguido exactamente y las consecuencias.

SSL es un protocolo que sirve para cifrar las comunicaciones punto a punto, por ejemplo entre un navegador y un servidor web o una conexión SSH. En una conexión SSH no es necesario autenticar al servidor remoto habitualmente, pero sí cuando un usuario se conecta a una página web. ¿Estoy realmente en la web de mi banco? Para eso se inventaron los certificados, que son una especie de “documentos de identidad”, DNI, del servidor. Ahí aparecen (respetando el estándar X.509) datos como el nombre de dominio para el que está emitido, fechas de validez, clave pública del sitio y sobre todo, qué autoridad le da validez a ese certificado. Si en el caso de los carnés de identidad la validez la certifica el Estado, en Internet existen un buen número de autoridades certificadores (CA) que validan esa información. Cuando se crea una clave pública que va a servir para certificar un sitio web, el dueño del sitio debe enviar esa clave junto con sus datos a una autoridad para que todo junto se convierta en un certificado y se garantice que pertenece a esa persona o entidad.

Las CA calculan el hash (una especie de firma-resumen) de todo el certificado (recordemos: nombre de dominio, fechas, clave pública…), y este valor se añade al propio certificado. Sería como su número personal e intransferible que lo incluye todo. Si se altera algún valor, este dato cambia por completo. Luego además “firman” este hash (y solo el hash) con su propia clave privada, de forma que ahora el certificado, tiene un “número de identificación”, firmado por alguien de confianza y supuestamente único, además asociado de forma indivisible a sus datos.

Este paso sería como “lacrar” el certificado en un sitio oficial. Como veremos, aquí es donde las CA cometen el error técnico.

Como existen muchas CA, los navegadores traen ya por defecto una lista de certificados raíz que sirven para comprobar de forma automática la ruta de validez del certificado, que está firmado por alguien en quien se confía.

Si existe algún fallo durante esta comprobación automática, si por ejemplo se crea un certificado que dice ser de un sitio pero no lo es y no está validado, el hash no casará y el navegador se quejará mostrando una alerta. Confiamos en los hashes firmados porque se supone que es muy complejo que dos hashes coincidan si son creados a partir de datos diferentes, esto es, que colisionen.

Cuando hablamos de hash o firma criptográfica, todavía se acude al MD5 como referente, aunque esté obsoleto y desaconsejado. Muchas CA han usado y están usando MD5 para calcular el hash del certificado y firmar esto con su clave privada. Otras muchas autoridades, la mayoría, están ya valiéndose de SHA1, un algoritmo de hash mucho más robusto y al que todavía no se le han encontrado serios problemas. MD5 por el contrario, es rechazado porque la potencia de computación actual hace que sea sencillo encontrar colisiones.

Esto es precisamente lo que han expuesto varios investigadores internacionales en Berlín el día 30 de diciembre. Han creado certificados con identidades usurpadas, pero validados por CA. Lo han conseguido con fuerza bruta, forzando la colisión de la firma MD5. Esto puede permitir crear sitios falsos con certificados que sean válidos, o de forma práctica: phishings perfectos.

Alegóricamente, lo que han conseguido es recortar un sello del Estado que da validez a un carné cualquiera y pegarlo en un carné falsificado de otro individuo al que se pretende imitar. El mérito del descubrimiento es que parezca real aunque los sellos son únicos y están creados a partir de los datos de todo el carné, además de lacrados por una autoridad.

Por ejemplo, si se quiere falsificar el certificado de hispasec.com, los investigadores crearían dos certificados, uno que falsificase los datos de Hispasec y otro real con cualquier información. El truco es que han conseguido con fuerza bruta, que ambos resulten en un mismo hash criptográfíco, en el mismo MD5. Entonces enviarían el real (con cualquier información no necesariamente relacionada con Hispasec) a una CA que todavía use MD5 para validar certificados. La CA lo firmaría y lo validaría con total normalidad. Luego los atacantes dan el cambiazo: les bastaría con modificar el hash del certificado que falsifica los datos de Hispasec con el hash del otro certificado, validado ya por una CA. Como ambos resultan en el mismo hash aunque contengan distintos datos, todo encaja, y el certificado falso seguiría siendo matemáticamente válido a todos los efectos.

No mucho. La tecnología SSL es muy útil, y ahora se le ha encontrado un pequeño hueco que hace que en teoría, podamos dudar de todos los certificados de autoridades certificadoras que se basen en MD5, pero son las que menos. En cualquier caso, el problema de base es que el usuario medio no sabe qué es SSL, ni qué significa un certificado, y mucho menos interpretarlo. Como mucho, sabe que si está en un sitio https, o el candado del navegador está activo, entonces el sitio es “bueno”. Pero ya sabemos que para conseguir un candado en el navegador o incluso un certificado no válido (aunque el navegador se queje, el usuario no entenderá la advertencia y dirá que “sí”) no es necesaria tanta complejidad. Un atacante puede comprar certificados baratos que validen un nombre falso (banc0.com), el navegador ni se quejará y el usuario tampoco entenderá qué está pasando.

SSL es técnicamente genial pero está resultado una tecnología “socialmente” fallida. No es entendida por el usuario y ese es el mayor de sus problemas. Con este golpe técnico la infraestructura de PKI se ha demostrado que incluso a los expertos se les podría engañar con los certificados, pero también es cierto que los que entienden la tecnología pocas veces se detienen a cuestionarse un certificado, comprobando la ruta de certificación y demás información proporcionada por el sitio supuestamente seguro. SSL arrastra la lacra del desconocimiento por parte de la mayoría de los usuarios.

Si por ejemplo el DNI es aceptado nacionalmente como documento que valida una identidad, un certificado SSL está lejos de ser aceptado por el usuario medio de Internet como documento que garantice nada.

También hay que tener en cuenta que pocas CA usan hoy día MD5, y que tras esta llamada de atención es de esperar que sean todavía menos en el futuro. Para los que posean certificados, es aconsejable que comprueben que la CA que les ha dado validez usa o no MD5.

En definitiva, esto es grave sobre todo para https, pero nada catastrófico va a pasar a efectos prácticos para el usuario medio. Al menos no más grave de lo que ya está ocurriendo, teniendo en cuenta la credibilidad de la que todavía gozan burdas copias de páginas web que simulan ser bancos.

Todos los grandes fabricantes (que usen VPN basadas en SSL o implementen navegadores) han publicado avisos explicando el problema.