Para aquellos de nuestros lectores que siempre nos agradecen por publicar contenido técnico, he mantenido el apartado en el que se habla de las vulnerabilidades de SSL/TLS a lo largo de los últimos años.
Las necesidades de cifrado
Esto implica que el canal a utilizar para realizar diversos trámites que involucran el intercambio, envío o consulta de datos personales, será Internet. Fundamentalmente este tipo de comunicaciones se llevarán a cabo mediante el estándar HTTP (Hypertext Transfer Protocol), utilizado por las transacciones de la World Wide Web.
Por ende, y por cumplir con la Ley Orgánica 15/1999, de Protección de Datos de Carácter Personal (LOPD), las diferentes Administraciones Públicas tendrán obligatoriedad de aplicar diversas medidas de seguridad, según la clasificación de los datos personales intercambiados.
Asimismo, y de forma específica para Administraciones Públicas, entra en juego, en Enero de 2010, el Real Decreto 3/2010, del 8 de enero, por el que se regula el Esquema Nacional de Seguridad en el ámbito de la Administración Electrónica.
Se puede observar que, de forma encadenada, y dado que se obliga a la Administración Pública a poner los datos de los ciudadanos en el escaparate de Internet, son los propios dirigentes quienes aprueban leyes que buscan exigir unos mínimos que garanticen que dichos datos serán accesibles de una forma segura.
A partir de aquí, queda en manos de cada Administración, que de forma independiente, implemente dichas medidas de seguridad, de manera más o menos estricta.
La primera pregunta que viene a la cabeza del lector es ¿Y esto se cumple de forma efectiva? Y en lectores cuyo nivel de sensibilidad con sus datos personales es aún mayor, la segunda pregunta obligada será: ¿Son estas medidas suficientes?
Sobre los protocolos SSL y TLS
Para dotar de una capa de cifrado a las comunicaciones electrónicas que utilizan típicamente el protocolo HTTP, los dos protocolos más utilizados son SSL (Secure Sockets Layer) y TLS (Transport Layer Security).
Ambos, son protocolos criptográficos que utilizan criptografía de clave pública (o asimétrica) para autenticar a una de las partes (obligatoriamente al servidor) o ambas, siendo opcional la autenticación del cliente.
Para dicha autenticación se utilizan certificados X.509, emitidos y firmados mediante una estructura jerárquica, con diferentes capas basadas en Autoridades Certificadoras y de Registro.
Cada certificado X.509 lleva información que identifica unívocamente a un individuo o una entidad, como el identificador único del sujeto (CN o Common Name, organización, ciudad y país) información relativa al emisor, desde cuándo y hasta cuándo es válido el certificado, la propia clave pública del individuo o entidad, así como el algoritmo utilizado para generarla.
Además, cada certificado contará también con información de la entidad más inmediata en la jerarquía que ha firmado el mismo, y que avala su autenticidad. La información añadida por la Autoridad de Certificados es el la firma digital del mismo, así como el algoritmo utilizado para realizar la firma, así como el algoritmo de hashing utilizado.
Gracias a la criptografía de clave pública, y mediante la utilización de las herramientas que ésta provee, es posible garantizar la autenticación en las comunicaciones, así como el no repudio en las transacciones, si éstas han sido firmadas digitalmente por una de las partes. Son también misión de los algoritmos de clave pública asegurar la verificación de una determinada firma digital.
Los algoritmos de clave pública típicamente utilizados en las difernetes fases, son DSA (Digital Signature Algorithm), RSA (Rivest, Shamir y Adelman) y Diffie-Hellman.
Como algoritmos de hashing, a la hora realizar firmas digitales, la criptografía de clave pública provee de MD5 (Message Digest) y aquellos de la familia SHA (Secure Hash Algorithm).
Tanto SSL como TLS, utilizan criptografía de clave pública para las fases de autenticación, intercambio de claves como de firma digital. Sin embargo, para el establecimiento de la comunicación y el intercambio de información entre las partes, se hace uso de criptografía de clave privada, o simétrica. A este grupo pertenecen algoritmos de cifrado como RC2, RC4, IDEA (International Data Encryption Algorithm), DES (Data Encryption Standard), Triple DES o AES (Advanced Encryption Standard).
Entre los diferentes algoritmos empleados para una misma tarea, se distingue, aparte del mecanismo de funcionamiento interno de cada uno, la longitud de clave utilizada. Cuanto mayor sea la longitud de la clave empleada para cifrar el mensaje, y siempre y cuando no se conozcan debilidades de base del algoritmo que aceleren el proceso, mayor será el esfuerzo computacional a realizar para descifrar el mensaje.
Otro concepto importante dentro de la criptografía es que un algoritmo se considera seguro, si el tiempo y el esfuerzo necesarios para romperlo y descifrar el contenido sin el conocimiento de la clave, es mayor que el valor del contenido de los datos en sí.
Con el paso de los años del mundo digital, el brillante trabajo realizado tanto por investigadores, como por gobiernos que ponen su foco en la intercepción y descifrado de las comunicaciones, la supuesta robustez los diferentes algoritmos criptográficos va siendo puesta en entredicho.
Por esto, cada implementación de SSL/TLS, va mejorando de una versión a otra, soportando cada vez algoritmos considerados más seguros, ya sea por mayor longitud de clave, como por la complejidad criptográfica del algoritmo en sí.
Para que dos extremos (cliente y servidor) establezcan una comunicación, previamente a que ésta exista, han de intercambiarse una lista de algoritmos de cifrado, hashing y firma soportados por cada lado, eligiéndose habitualmente aquellos más robustos. Esto es así, debido a que la implementación SSL de los clientes y servidores no siempre soporta los mismos algoritmos, asegurando la compatibilidad con dispositivos más antiguos, o más limitados en cuanto a recursos de cómputo.
SSL/TLS a día de hoy
Hablar de “el día de hoy”, en un universo tan volátil y en el que cada mañana se hace pública una nueva vulnerabilidad, se hace complicado. Para ilustrar el estado del arte de SSL/TLS, empezaremos referenciando las últimas vulnerabilidades conocidas para estos protocolos.
Un repaso al historial de vulnerabilidades de SSL/TLS
Ya en el año 2011, desde la publicación de BEAST, la industria del software e Internet sufrió un gran revuelo. En 2012, Thai Duong y Juliano Rizzo, publicaron CRIME, otra vulnerabilidad explotable bajo determinadas condiciones, que aprovechaba un fallo en la compresión de los protocolos HTTPS y SPDY.
Pero sin duda, ha sido 2014 el año en el que SSL se haya visto más afectado. Posiblemente, el que mayor repercusión mediática tuvo, fue
Heartbleed, ya que permitía leer de forma remota bloques de memoria del servidor. Esto implicaba que un atacante, desde la otra punta del mundo, podía extraer información de uso reciente en el servidor, como credenciales, cookies, e incluso la clave privada SSL utilizada. De esta manera, un atacante sería capaz, bajo ciertas condiciones, de interceptar la comunicación entre cliente y servidor, descifrándola o incluso suplantar a éste. Posteriormente, se descubrió que Heartbleed también podría afectar al lado cliente, siempre y cuando éste sea vulnerable y acceda a un servidor malicioso. Esta modalidad de Heartbleed se terminaría bautizando como
Reverse Heartbleed.
A mediados de año, OpenSSL publicaba una nueva versión que corregía varios problemas serios. La vulnerabilidad más grave permitía que un atacante en un entorno Man-in-The-Middle, inyectase mensajes ChangeCipherSpec (CCS) a ambos lados. Como resultado de este ataque, se generan claves débiles que permiten descifrar la comunicación.
A finales de 2014 apareció POODLE (Padding Oracle On Downgraded Legacy Encryption) afectando a software que utilizase la versión 3.0 de SSL y posteriormente, una variante que afectaba a TLS. Este tipo de ataque, sería aplicable en escenarios en los que es posible previamente interceptar las comunicaciones entre cliente y servidor, mediante un ataque de Man-in-The-Middle. Esto es necesario debido a que requiere el análisis de un gran volumen de información entre ambos extremos para poder descifrar parte de la misma. Si bien es cierto que sólo afectaba a SSL 3.0, y que ciertos servidores incorporaban TLS, POODLE se basaba en ejercer previamente un ataque de downgrade de protocolos en la negociación inicial entre las partes, de manera que la comunicación se estableciese por SSL v3.
Las vulnerabilidades mencionadas afectaban fundamentalmente a las implementaciones SSL de OpenSSL, y por tanto todos aquellos dispositivos que se basasen en ella. En algunos casos, también afectaba a la implementación SSL de otros sistemas operativos como Android, Windows o Mac OS X.
Pero en 2014 no sólo las implementaciones de OpenSSL se vieron afectadas, sino también se descubrieron vulnerabilidades en la implementación de fabricantes como Apple (
con el famoso GotoFAIL) o en el mundo del software libre, a GnuTLS.
Precisamente, se aprovecha de un fallo en la negociación inicial, que permite forzar que se utilicen especificaciones de algoritmos RSA con longitudes de clave muy cortas, consideradas crackeables en un tiempo moderado, con los recursos computacionales necesarios. Algoritmos del tipo de TLS_RSA_EXPORT_WITH_DES40_CBC_SHA, estaban aún soportados por el estándar SSL/TLS, por compatibilidad con las restricciones de cifrado establecidas por el gobierno Clinton en Estados Unidos, en los 90, para aquellas comunicaciones que se llevasen a cabo fuera del país.
Y ya en Mayo de 2015, el último hit a SSL ha sido Logjam. En este caso, el ataque se establece dentro del algoritmo Diffie-Hellman, cuando se usan de 512 a 1024 bits. Una vez más, en un entorno de Man-in-The-Middle, es posible para un atacante establecer un downgrade de la negociación para utilizar un algoritmo de Diffie-Hellman de longitud baja, soportadas también desde épocas en las que existían limitaciones de cifrado a la hora de ser exportado fuera de Estados Unidos. Esta vulnerabilidad permitía comprometer el cifrado no sólo a HTTPS, sino a otros protocolos como SMTPS, SSH, IPSec y aquellos que confíen en TLS.
De hecho, se especulaba con que Logjam era la vulnerabilidad utilizada por la NSA para poder descifrar tráfico en el programa americano de ciberguerra llamado TURBULENCE.
Han existido otros ataques a SSL/TLS que han tenido menos repercusión mediática, como Lucky13 o Bar Mitzvah, pero que permitían igualmente descifrar contenido parcial o totalmente de las comunicaciones.
Los algoritmos de hashing más populares, MD5 y SHA-1, también han sido reconocidos como no-confiables debido a que en ambos es posible establecer colisiones, de manera que hace que se incumplan por definición, al poder llegarse a dos hashes MD5 o SHA-1 idénticos, partiendo de fuentes distintas.
Tras ver la cantidad de vulnerabilidades existentes en diversas implementaciones de SSL/TLS, se considera que
SSL está “muerto” y que la única implementación viable es TLS, actualmente en su versión 1.2. No se puede decir que esta especificación sea la definitiva y la segura, pero al menos, a día de hoy, no se conocen vulnerabilidades que hagan pensar lo contrario.
De hecho, navegadores como Firefox, a partir de su versión 34, deshabilitan SSLv3, confiando en TLS únicamente.
Implementación de SSL/TLS en los Ayuntamientos Españoles
Para el estudio realizado, se ha escogido una muestra representativa de ayuntamientos españoles, de 10 capitales de provincia, repartidos por la geografía española. Las entidades elegidas fueron, los ayuntamientos de las ciudades de Barcelona, Bilbao, Cáceres, Logroño, Madrid, Málaga, Pontevedra, Santiago de Compostela, Sevilla y Valencia.
Como herramienta de métricas estándar, se ha elegido la solución online
https://www.ssllabs.com/ssltest, provista de forma gratuita por Qualys Labs. El servicio provisto es online y gratuito.
La prueba consiste en introducir el dominio de cada ayuntamiento en la que el protocolo a servir es HTTPS. Se ha identificado para cada prueba, alguna dirección web a través de la que se envíen datos personales a cada Ayuntamiento.
Por cada prueba, la herramienta ofrece un resultado como el que se puede apreciar en la imagen. En ella se puede observar el dominio y la dirección IP correspondiente, el rating o nota que da el servicio ante multitud de pruebas realizadas, así como un resumen de aquellas mejoras que se pueden hacer para que el servicio tenga una mayor seguridad. El rating va desde la F que es el peor resultado, hasta el A+ que es el mejor.
Asimismo, el contenido del informe detalla cada una de las pruebas realizadas.
Este servicio evalúa tanto la información del certificado SSL ofrecido por el servidor para el dominio analizado, como la configuración propiamente del mismo, en base a analizar las respuestas de éste.
Por confidencialidad, en este informe se establece un resumen de resultados, sin asociarlos a un Ayuntamiento concreto.
Análisis de los resultados
Tras la revisión de cada uno de los informes generados por el servicio online se extrae los siguiente:
- La nota más alta otorgada a un Ayuntamiento es la B, y la más baja es la F. En tres casos de los diez analizados, la nota obtenida es T, que quiere decir que el certificado no es confiable (Trustable). Esto se da porque el certificado está firmado por la FNMT (Fábrica Nacional de Moneda y Timbre), autoridad de certificados reconocida en España y por el navegador Internet Explorer. Sin embargo, otros navegadores como Google Chrome o Mozilla Firefox no la reconocen como válida, y muestran un error de certificado al cargar la página. En un caso, la nota obtenida se identifica como M (Mismatch) puesto que el nombre de dominio no coincide con el del certificado ofrecido. Esta situación mostraría un error de certificado no confiable en todos los navegadores. Si no se tiene en cuenta la nota T o M, quedaría según muestra la siguiente relación:
- Nota B: 3 ayuntamientos
- Nota C: 2 ayuntamientos
- Nota F: 5 ayuntamientos
- El servidor muestra el nombre del fabricante y su versión y/o de mod_ssl -> 4 ayuntamientos. Sólo el fabricante del servidor 4
- El servidor de uno de los ayuntamientos analizados soporta SSLv2, considerado inseguro desde hace varios años.
- El servidor es vulnerable a POODLE. Ya sea por soporte de SSLv3 como por TLS, al no soportar la extensión TLS_FALLBACK_SCSV, que mitigaría este problema. Se considera que SSLv3 es inseguro y se recomienda deshabilitarlo http://disablessl3.com/ -> 7 de los 10 ayuntamientos analizados
- El servidor es vulnerable a FREAK. 3 ayuntamientos de los 10 analizados
- El servidor es vulnerable a CRIME: Sólo un ayuntamiento es vulnerable a CRIME por tener activo el soporte de compresión en TLS.
- El servidor es vulnerable y explotable a ChangeCipherSpec CCS, 2 de 10 ayuntamientos.
- El servidor soporta parámetros inseguros de intercambio de claves Diffie-Hellman, 8 de los 10 ayuntamientos.
- El servidor utiliza primos comunes/conocidos para algoritmo Diffie-Hellman: 6 de 10 ayuntamientos.
- Soporte del algoritmo de cifrado RC4. Aunque la herramienta indica que soportar RC4 se considera un algoritmo débil, hay que dejar claro que nuestro desacuerdo en ello. La supuesta vulnerabilidad de RC4, supone al atacante estar en un entorno Man-in-The-Middle capturando el tráfico de la víctima hacia el servidor. Esto es perfectamente viable, pero es que además el atacante deberá recopilar una cantidad ingente de los mismos datos cifrados con diferentes claves, lo que inicialmente disminuye la probabilidad de ocurrencia del ataque. No obstante, se destaca que 8 de los 10 ayuntamientos anaizados, soportan RC4.
- Sólo soportan TLS v1.2 en 6 de 10 ayuntamientos analizados, aunque en todos ellos, se soporta al menos TLS v1.0, siendo bastante común el tandem SSLv3 y TLSv1.0, sin dar soporte para TLS v1.1 ni v1.2
- Respecto al algoritmo de firma del certificado SSL presentado por el servidor:
- Dos ayuntamientos utiliza clave privada con RSA de 1024 bits, considerada una longitud de clave insuficiente.
- El algoritmo de hashing utilizado en el certificado es SHA-1 en 8 de 10 ayuntamientos.
- De estos ocho, en cuatro de ellos, la fecha de expiración del certificado es mayor de finales de 2016. A partir de esta fecha, Microsoft ha anunciado que dejará de soportar SHA-1 como algoritmo válido en sus navegadores, por lo que se mostrará el certificado como erróneo.
Conclusiones y reflexiones
Tras haber desglosado los diferentes ataques de los que pueden ser víctimas, tanto los servidores, como sobre todo los clientes, que intercambian datos mediante una conexión SSL/TLS, se puede ver que mantener los servicios lo de la forma más segura posible es una labor que requiere dedicación y mantenimiento.
No sólo se trata de actualizar los parches de seguridad, y tener todo el software a la última versión, sino que además, los servicios que hacen uso de SSL, deben estar configurados de forma segura, manteniendo unos niveles de compatibilidad con los algoritmos de cifrado soportados por los dispositivos y sistemas operativos más comunes del mercado.
En muchas ocasiones merece la pena sacrificar la conectividad de aquellos dispositivos más antiguos, en pos de evitar la posibilidad del compromiso completo de los datos de otros usuarios.
La administración pública suele tenernos acostumbrados a los ciudadanos a que, para poder interactuar con la e-Administración, tengamos que disponer de una determinada versión de la máquina virtual de Java, o al menos no podamos disponer la última. Igualmente, en muchas ocasiones, se ve limitado el navegador con el que podemos acceder a determinados servicios, siendo Internet Explorer para que el que parece que la Administración hace sus pruebas de compatibilidad. Incluso dentro de Internet Explorer, se solicita al internauta que relaje las medidas de seguridad, para que funcione. ¿Y después de todos estos requisitos, se pretende que los ciudadanos tengan tranquilidad sobre el tratamiento de sus datos?
Cada vez que vemos un telediario, que analizamos las noticias relacionadas con los avances de la Agencia Nacional de Seguridad americana (NSA), desvelados por Edward Snowden, y los descubrimientos publicados día a día, cada vez se genera una mayor sensación de inseguridad en los ciudadanos.
Las debilidades de los algoritmos de cifrado empleados en las comunicaciones, permitirían el acceso a quien tuviera el conocimiento de la existencia de una vulnerabilidad. Sin embargo, una vez que los detalles de éstas se hacen públicas, es la propia comunidad quien se lanza a construir exploits y herramientas automatizadas que permitan su explotación a cualquiera con unos conocimientos mínimos. De ahí la importancia vital de que cualesquiera sean los sistemas, cuenten con las últimas versiones y parches de seguridad, sean configurados de la forma más exigente y segura posible, así como que formen parte de un programa frecuente de auditorías, con el fin de disminuir los riesgos al mínimo posible.
Los resultados que se desprenden del estudio realizado sobre la muestra de 10 ayuntamientos, muestran cómo en las ciudades de mayor volumen de habitantes, las medidas de seguridad implantadas en los servidores, son algo más cuidadas, siendo los ayuntamientos más pequeños los que muestran claramente que tienen aún bastante por mejorar.
Desde un punto de vista meramente legal, y atendiendo a las normativas referidas respecto al tratamiento de datos personales, como LOPD o, en el caso de Administración Pública, el Esquema Nacional de Seguridad, en lo que se refiere al cifrado de las comunicaciones, se puede decir que todos los Ayuntamientos menos uno, cumplen con que el tráfico intercambiado entre cliente y servidor “no sea inteligible ni manipulada por terceros”. Sin embargo, y pese a estar al día con la normativa vigente, sigue habiendo una diferencia entre cumplir una ley y tener una conciencia real de seguridad de la información.
JAIME PEÑALBA (
