La ciberseguridad es un campo en constante evolución, con nuevas amenazas, lagunas y exploits que se descubren y abordan continuamente.
Esta batalla constante contra los ciberdelincuentes presenta un desafío excepcional para los expertos en seguridad, ya que el exploit del mañana puede comprometer el tráfico de hoy, un problema para el cual se inventó el «Perfect Foward Secrecy». Entonces, ¿qué es Perfet Foward Secrecy (secreto directo perfecto)? Sigue leyendo este artículo para averiguarlo.
Indice
¿Qué es Perfect Foward Secrecy?
En resumen, el acrónimo PFS significa «secreto directo perfecto», que es una característica de seguridad relativamente reciente para sitios web. Su objetivo es evitar que futuras vulnerabilidades y brechas de seguridad comprometan la comunicación, la información o los datos actuales o pasados al aislar el cifrado de cada transacción.
Tradicionalmente, los datos cifrados estarían protegidos por una única clave de cifrado privada mantenida por el servidor, que podría usar para descifrar toda la comunicación histórica con el servidor usando una clave pública. Esto presenta un riesgo de seguridad potencial en el futuro, ya que un atacante puede pasar semanas, meses o años escuchando el tráfico cifrado, almacenando los datos y esperando su momento.
Es un método criptográfico para garantizar la seguridad de las transacciones de datos entre un cliente y un servidor.
Garantiza que las claves de sesión no se verán comprometidas, revelando comunicaciones pasadas, incluso si un atacante revela las claves privadas de un intercambio en particular. Esto se logra generando nuevas claves de sesión (efímeras) para cada transacción.
Si bien PFS ofrece un alto grado de seguridad, no es un método infalible y es vulnerable a infracciones en el contexto de un ataque de intermediario (MITM).
Con todos estos datos en la mano, todo lo que el atacante debe hacer es esperar cualquier posible vulnerabilidad de seguridad futura que le permita tener en sus manos la clave privada del servidor, que luego puede usarse para descifrar todos los datos que ha estado recolectando.
Importancia
Perfect Foward Secrecy resuelve este problema al eliminar la dependencia de una clave privada de un solo servidor. En lugar de utilizar la misma clave de cifrado para cada transacción individual, se genera una nueva clave de sesión única cada vez que se produce una nueva transacción de datos.
Esto significa que incluso si un atacante logra obtener una clave de sesión, solo será útil para descifrar la transacción más reciente, en lugar de todos los datos que pueda haber recopilado en el pasado.
En lugar del intercambio de claves RSA estándar, estas claves de sesión se generan utilizando el cifrado Diffie-Hellman o, mejor aún, el cifrado Diffie-Hellman de curva elíptica. Las claves de cifrado son efímeras, lo que significa que no se almacenan en ningún lugar y no se pueden reutilizar para una transacción posterior.
De manera similar, la clave privada del servidor será completamente inútil para el atacante porque no se puede usar para descifrar el tráfico entre el servidor y los clientes.
Aunque este método de ataque puede requerir más paciencia y recursos de los que tiene acceso un solo ciberdelincuente, no se puede decir lo mismo de las organizaciones de inteligencia.
Entidades como la Agencia de Seguridad Nacional tienen fácilmente la capacidad de escuchar muchas conexiones encriptadas, llegando incluso a interceptar los cables submarinos gigantes que conectan servidores en todos los continentes.
Esta capacidad masiva para recopilar datos, combinada con la paciencia institucional de una organización como la NSA, significa que tienen pocos problemas para recopilar y almacenar grandes cantidades de datos cifrados.
En el caso de que se presente algún exploit o laguna en el futuro, que les permita tener en sus manos la clave privada requerida, pueden usar esta clave de cifrado para descifrar potencialmente millones o miles de millones de transacciones de datos de un solo golpe.
¿Cómo funciona?
La implementación de la confidencialidad directa perfecta es una forma de evitar los peligros asociados con el robo de la clave privada de un servidor. PFS supera esta vulnerabilidad utilizando un algoritmo de intercambio de claves que es independiente del método de cifrado. De esta forma, el proceso de autenticación se separa del de encriptación.
Esto se logra mediante el uso del mecanismo de intercambio de claves Ephemeral Diffie-Hellman (DHE) o Ephemeral Elliptic Curve Diffie-Hellman (ECDHE).
En este escenario, la clave privada del servidor todavía se usa para la autenticación, pero uno de los dos mecanismos anteriores se usa para acordar el secreto maestro, es decir, la clave de sesión. Esta es una clave de sesión efímera, lo que significa que el servidor generará nuevos parámetros Diffie-Hellman para cada sesión (o un solo mensaje, carga de página, etc.).
Dado que estos parámetros nunca se pueden reutilizar, se consideran efímeros y, por lo tanto, ofrecen una capa adicional de seguridad entre la clave privada y la clave de sesión, así como entre sesiones.
Además, cuando se utiliza un intercambio de claves Diffie-Hellman, los servidores y los clientes no intercambian las claves de sesión de la manera típica, durante el proceso de reconocimiento. En su lugar, ambas partes generan una clave de sesión de forma independiente, sin conocimiento previo de la otra parte. Esto significa que la clave de sesión no se puede obtener monitorizando los datos transferidos en ese momento. Y, debido a la complejidad de las operaciones matemáticas involucradas en la generación de una sola clave de sesión, no se puede lanzar un ataque de fuerza bruta de manera efectiva para piratear la clave.
Finalmente, incluso si un atacante logra obtener la clave de sesión, los datos que podrá recuperar son muy pequeños. Esto hace que el secreto directo perfecto sea un método de protocolo de acuerdo de claves seguro.
Cómo PFS mantiene tu sitio web seguro
La forma más obvia en que el secreto directo perfecto mantiene seguro tu sitio web es brindándote a ti y a tus usuarios seguridad adicional en caso de una violación de datos. En el peor de los casos, un atacante solo podrá descifrar una sola transacción de datos y, aunque esto aún podría presentar un riesgo, el daño está contenido en gran medida.
Además, los servidores que emplean el secreto directo perfecto presentan objetivos menos atractivos para los atacantes. Aunque todavía hay información almacenada en el servidor que está protegida por la clave privada original, esto es todo lo que el atacante podrá tener en sus manos, lo que limita significativamente la recompensa del ataque.
Por supuesto, esto no es garantía contra un ataque, pero lo hace menos probable, ya que los atacantes podrían optar por objetivos más gratificantes.
Google fue una de las primeras grandes empresas de software en implementar el secreto directo perfecto en sus servidores. Debido a esto, es muy probable que, en algún momento en el futuro, Google use su posición como el motor de búsqueda dominante para alentar la adopción de PFS al recompensar a los sitios que lo emplean clasificándolos más alto en sus resultados de búsqueda, como lo fue el caso con HTTP frente a HTTPS.
Dónde se usa
PFS es y ha sido fuertemente adoptado por los proveedores de información desde sus inicios, y es conocido como una característica de seguridad crucial.
Un ejemplo es Signal, el protocolo de mensajes para el cifrado de extremo a extremo que ahora se usa en WhatsApp, Google Allo y Facebook Messenger, lo que hace que PFS sea más popular.
Conocido como el sistema de «doble trinquete», el protocolo de señal crea una nueva clave para cada mensaje. Más recientemente, ha surgido una nueva función que permite que los mensajes se autodestruyan.
Uno de los primeros casos de uso fue en 2011 cuando Google comenzó a entregar Gmail, GSuite, todavía llamado Google Docs, y para sus usuarios que usan su motor de búsqueda, una comunicación mediante PFS.
Además, Twitter también comenzó a ofrecer PFS a todos los usuarios desde 2013. En 2016, Apple comenzó a adoptar un nuevo protocolo obligatorio para todas las aplicaciones de iOS que requieren el uso de App Transport Security.
Perfect Forward Secrecy y Heartbleed
Tal vez no haya mejor ejemplo de por qué es esencial Perfect Foward Secrecy que el infame exploit Heartbleed. Para entender por qué, es importante saber primero qué es Heartbleed y por qué fue tan dañino.
Heartbleed explota un error introducido en 2012 en OpenSSL, una de las implementaciones más populares del protocolo TLS (seguridad de nivel de transporte), pero esto no se descubrió hasta dos años después, en 2014.
Entendiendo SSL/TLS
No necesitas saber exactamente cómo funciona TLS, pero en resumen, es un protocolo de seguridad que cifra el tráfico entre un cliente y un servidor utilizando una clave de cifrado privada, siendo HTTPS el ejemplo con el que probablemente estés más familiarizado.
El error aprovecha la extensión Heartbeat para TLS, que está diseñada para probar la comunicación TLS mediante el envío de una carga útil (generalmente un poco de texto), así como un número que especifica el tamaño de la carga útil. Luego, el servidor responde devolviendo la carga útil al remitente original.
El problema era que el servidor en realidad no verificaba el contenido de la carga útil, sino solo el número que especificaba su tamaño. Usaría este número para recuperar una cierta cantidad de datos del búfer de memoria, que estaba destinado a ser solo la carga útil original enviada al servidor.
Sin embargo, debido a que no se verificó la carga útil en sí, esto abrió la posibilidad de enviar una carga útil más pequeña que la especificada en el número que representa su tamaño. Esto dio como resultado que el servidor devolviera no solo la carga útil original, sino también información adicional almacenada en el búfer de memoria para alcanzar el tamaño de mensaje solicitado.
Heartbleed en acción
Como ejemplo, el mensaje Heartbeat malicioso podría solicitar al servidor que devuelva la palabra «prueba», pero especificar que la longitud debe ser de 500 caracteres. Esto llevaría al servidor a devolver la palabra solicitada «prueba», pero también 496 caracteres adicionales de la memoria.
Aunque el atacante no tendría forma de determinar exactamente qué información obtendría, existe una buena posibilidad de que estos caracteres adicionales contengan información confidencial, como la clave privada del servidor.
Por lo tanto, una vez que Heartbleed apareció en escena, cualquier ciberdelincuente que hubiera pasado algún tiempo escuchando el tráfico cifrado de repente tenía una vía de ataque perfecta para adquirir la clave privada de cualquier servidor expuesto al error.
Usando estas claves de cifrado, pudieron descifrar todos los datos que habían recopilado previamente, lo que resultó en una gran cantidad de información comprometida.
Vulnerabilidades
Perfect Foward Secrecy contiene varias vulnerabilidades posibles.
PFS está destinado a impedir que los atacantes obtengan claves de sesión que les permitan descifrar las comunicaciones. Lo que no puede evitar es un ataque que busca influir en cómo se genera la clave de sesión, es decir, la clave de cifrado.
Si un atacante es capaz de modificar el funcionamiento del generador de claves de sesión, haciendo predecibles los valores aleatorios que se generan para el intercambio de claves, podrá descifrar todas las comunicaciones futuras. Este era el problema con el generador de bits aleatorios deterministas de curva elíptica dual que tenía una puerta trasera que permitía modificar el generador de esa manera.
El secreto directo perfecto tampoco protege contra un ataque de intermediario (MITM) en el que un atacante puede registrar y modificar las comunicaciones entre un servidor y un cliente. Si bien PFS protege contra el descifrado de dicha comunicación, no puede evitar que se recopile, si un atacante se posiciona en el medio. En principio, obtener y mantener tales registros deja la puerta abierta para que puedan ser descifrados en el futuro, una vez que la computación cuántica esté más ampliamente disponible.
Aunque no es una vulnerabilidad en sí misma, una de las razones de la lenta adopción de PFS a mayor escala son los recursos informáticos adicionales que requiere el servidor para generar claves de sesión únicas. PFS también carece de soporte heredado, lo que también limita un poco su implementación.
Finalmente, la implementación de PFS da como resultado una falta de visibilidad interna de los datos. Dado que cifra las comunicaciones de la red, los equipos técnicos no pueden localizar los problemas y solucionarlos porque no pueden descifrar el tráfico. Existen soluciones para este problema, como instalar un dispositivo de inspección SSL/TLS para que actúe como intermediario.
Protección en un mundo poscuántico
La proliferación de computadoras cuánticas es inevitable, y en realidad es solo cuestión de tiempo antes de que estén disponibles para el uso del público en general. Cuando llegue ese día, hará que muchos algoritmos criptográficos sean inútiles, exponiendo datos que originalmente se pensaba que estaban protegidos. Entonces, ¿qué impide que un pirata informático recopile datos cifrados ahora con la intención de guardarlos hasta que pueda tener en sus manos una computadora cuántica y descifrarla?
La respuesta es nada. De hecho, muchos ciberdelincuentes están llevando a cabo actualmente este tipo de ataque, comúnmente conocido como “cosechar y descifrar”. Específicamente, actualmente están llevando a cabo la parte de «cosecha» del ataque, mientras que la parte de «descifrado» tiene que esperar a la computación cuántica. Sin embargo, esperar unos años es un pequeño precio a pagar si el resultado final es el descifrado de información de alto valor como secretos de estado, registros financieros o propiedad intelectual confidencial.
Entonces, ¿dónde entra en juego el secreto directo perfecto? Protege tus datos debido a los métodos de encriptación simétrica utilizados. Una computadora cuántica no puede romperlo porque no tendrá todas las piezas del rompecabezas que necesita. La clave de sesión no se intercambia a través de la red, sino que ambas partes la generan de forma independiente en función de ecuaciones complejas.
Sin embargo, sin PFS y el cifrado simétrico, tus datos son vulnerables a un ataque de recolección y descifrado. Veamos un protocolo de enlace SSL/TLS estándar, por ejemplo. Si puede romper la clave privada privada asimétrica, entonces puede usarla para descifrar el protocolo de enlace. Entonces tienes lo que necesitas para determinar la clave de sesión.
Cosas que debes saber antes de implementar Perfect Forward Secrecy
Antes de implementar Perfect Forward Secrecy en tu sitio web, hay algunas cosas que debes saber:
- Se necesita más potencia de procesamiento. Esto se debe a que se debe generar una clave de sesión única para cada nueva transacción. De los dos algoritmos de intercambio de claves que discutimos, ECDHE es el más rápido de los dos, pero aun así genera un mayor requisito de procesamiento de aproximadamente un 20 %. Esto podría conducir a ralentizaciones que pueden afectar a sus clientes.
- Falta de soporte heredado. Si bien casi todos los navegadores y sistemas operativos actuales admiten la confidencialidad directa perfecta, los servidores y sistemas operativos más antiguos no lo hacen. Esto es algo a tener en cuenta si todavía estás utilizando hardware antiguo en algún lugar de tu organización.
- Sin visibilidad interna de los datos. Con el secreto directo perfecto, tus propios equipos internos no verán sus comunicaciones de red cifradas. Si tienes problemas con el servidor, por ejemplo, puede hacer que diagnosticarlos y solucionarlos sea un desafío mayor de lo que sería de otra manera. Sin embargo, existen soluciones para esto, como instalar un dispositivo de inspección SSL/TLS en el servidor.
- Qué cifrados ya está usando su servidor. Puedes verificar en tu navegador para ver qué cifrado está utilizando su conexión HTTPS.
Cómo habilitar PFS en tu servidor
Habilitar la función Perfect Forward Secrecy en tu servidor es en realidad un proceso muy sencillo que no requiere una cantidad significativa de esfuerzo por parte del administrador del sistema.
Obviamente, el proceso varía según la arquitectura del servidor que estés empleando, por lo que te mostraremos cómo hacerlo con Apache y Nginx, dos arquitecturas populares.
En general, lo que debes hacer es configurar tu servidor para priorizar los conjuntos de cifrado DHE y ECDHE, pero aún debes conservar la compatibilidad con RSA como respaldo. Esto se debe a que es posible que los sistemas y navegadores más antiguos no sean compatibles con PFS, lo que significa que no podrán cargar tu sitio a menos que te asegures de que todavía hay otros conjuntos de cifrado disponibles.
Para obtener instrucciones más específicas, hemos compilado una guía paso a paso sobre cómo habilitar el secreto directo perfecto en los servidores Apache y Nginx.
Apache
Para habilitar PFS en un servidor Apache, estos son los pasos que debes seguir:
- Ubica tu configuración SSL con el comando: “grep -I -r “SSLEngine” /etc/apache”
- Haz cumplir el orden de cifrado escribiendo: «SSLProtocol all -SSLv2 -SSLv3 SSLHonorCipherOrder on»
- Establece el orden de cifrado de esta manera: «ssl_ciphers ‘EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH’;»
- Finalmente, reinicia Apache con el comando: “apachectl -k restart”.
Nginx
Instalar PFS en el servidor Nginx requiere los siguientes pasos:
- Localiza tu configuración SSL escribiendo: «grep -r ssl_protocol nginx base directory» (reemplaza «nginx base directory» con la ruta adecuada)
- Modifica la configuración ingresando: “ssl_protocols TLSv1.2 TLSv1.1 TLSv1; ssl_prefer_server_ciphers en;”
- Establece el orden de cifrado escribiendo el comando: “ssl_ciphers ‘EECDH+AESGSM:EDH+AESGCM:AES256+EECDH:AES256+EDH’;”
- Reinicia Nginx con el siguiente comando: «sudo service nginx restart».
Conclusión
A medida que el protocolo TLS ha avanzado, el concepto de secreto directo perfecto ha seguido creciendo en importancia. Con esta evolución ha venido una mayor adopción para su implementación por parte de navegadores web, sistemas operativos, software de comunicación y gigantes de la industria en todo el mundo. Como resultado, cada vez más propietarios de sitios pueden usarlo para aumentar aún más la seguridad y proteger sus datos.
Si estás utilizando sistemas heredados sin confidencialidad directa perfecta, deberías considerar seriamente la posibilidad de actualizar. Tomará algo de tiempo y esfuerzo, pero al final es un pequeño precio a pagar por los beneficios proporcionados. Serás un objetivo mucho menos atractivo para los atacantes, ya que incluso un ataque exitoso no les dará mucho.
De cualquier manera, la industria se está moviendo en la dirección del secreto perfecto y es inevitable que sea un requisito en el futuro. Depende de ti hacer el cambio ahora o esperar hasta que sea absolutamente necesario. Sin embargo, si manejas información confidencial o estás sujeto a las leyes de regulación de datos, entonces debes adoptar Perfect Foward Secrecy lo antes posible.