El proyecto OpenSSL publicó ayer la primera alfa de su próxima versión con tres platos fuertes. El nuevo DTLS, el mecanismo GREASE y optimizaciones AVX-512 para criptografía postcuántica en la librería que cifra buena parte de Internet.
Recordemos que OpenSSL, es la librería de código abierto que protege las conexiones de millones de servidores, aplicaciones y dispositivos. Cada vez que tu navegador muestra el candado, hay muchas papeletas de que ella esté detrás. Por eso, una alfa suya es noticia aunque todavía no deba instalarse en ningún sitio serio.
Porque conviene dejarlo claro desde el principio. Esto es una versión de pruebas, no apta para producción, y la fecha de la 4.1 final ni siquiera está fijada.
Cinco meses después de la 4.0 llega la primera alfa
La 4.0 final salió el 14 de abril con una gran novedad: la llegada del HELLO cifrado al servidor (conocido como ECH), más criptografía postcuántica y una limpieza de protocolos viejos, según anunció el proyecto. Fue una versión de transición con fecha de caducidad cercana. El proyecto la mantendrá hasta el 14 de mayo de 2027, mientras la veterana 3.5 sigue como rama de soporte extendido (LTS).
Desde entonces, el mantenimiento no se ha detenido. A finales de agosto llegó la 4.0.2 con un parche de severidad moderada que evitaba un consumo excesivo de memoria al procesar registros DTLS de épocas futuras. La alfa 1 de la 4.1 se apoya sobre esa base ya endurecida y añade funcionalidad nueva de verdad.
La lista oficial de cambios confirma el menú. Soporte de DTLS 1.3 según el RFC 9147, con su guía de uso incluida. Soporte de GREASE según el RFC 8701, activable con la opción SSL_OP_GREASE y con un flag -grease para la herramienta s_client. Y un primer soporte para los procesadores rusos Elbrus 2000, además de la jubilación definitiva de Itanium y Windows CE en el lado de Windows.
Tres piezas merecen explicación pausada. Vamos con ellas.
DTLS 1.3, el cifrado para un Internet que no espera
TLS, el protocolo del candado, viaja sobre TCP, que garantiza que cada paquete llega en orden. Pero hay un mundo entero que no usa TCP. Las videollamadas, la voz sobre IP, muchas VPN, los juegos en línea y los sensores del Internet de las cosas hablan UDP, donde los paquetes pueden perderse o llegar desordenados. Para ellos existe DTLS, el gemelo de TLS adaptado a datagramas.
El problema es que ese gemelo llevaba años anclado en el pasado. OpenSSL entendía DTLS 1.0 y 1.2, pero la versión 1.3, publicada como estándar en abril de 2022, seguía sin aparecer. Cuatro años después, la alfa la trae por fin.
FreeBSD porta el software ROCm de AMD para HPC e IA en GPU
DTLS con vitaminas
Y trae mucho. El apretón de manos inicial entre computadores en Internet pasa de dos viajes de ida y vuelta a uno solo, así que conectar es más rápido. Solo se admiten cifrados modernos con autenticación integrada, todo lo anterior se mantiene allí por compatibilidad hasta ser retirado, pero el protocolo por defecto es seguro por diseño.
Además, cada sesión usa claves efímeras que se destruyen al terminar, de modo que robar la clave del servidor mañana no permite descifrar lo grabado hoy. Y hay hueco nativo para la criptografía postcuántica que resistirá a los ordenadores cuánticos del futuro.
Hay más detalles finos para redes hostiles. Un mecanismo de cookie obliga al cliente a demostrar su dirección antes de que el servidor invierta trabajo, lo que frena los ataques de denegación de servicio tan fáciles en UDP. Los mensajes grandes se fragmentan y reensamblan sin depender del sistema operativo. Y se pueden reanudar sesiones con datos desde el primer paquete, el llamado 0-RTT, para latencias mínimas.
Seguridad y velocidad, por fin juntas. Y para los programadores hay regalo extra. La API de escucha de OpenSSL ahora atiende DTLS además de QUIC, separando los datagramas entrantes por cliente de forma ordenada. Menos código artesanal en cada servidor, mayor seguridad e integración en el desarrollo.
GREASE o el WD-40 de Internet
La segunda pieza tiene el nombre más divertido de la criptografía reciente y su nombre es GREASE. Este protocolo responde a un problema casi filosófico: TLS está diseñado para evolucionar, con listas de capacidades donde el cliente ofrece y el servidor elige, ignorando lo que no conozca.
Pero algunos programas tienen errores y rompen la conexión ante valores desconocidos. Como con los clientes actuales todo funciona, el error se extiende en silencio. Años después, cuando llega una capacidad nueva de verdad, resulta imposible desplegarla, toca ensuciarse las manos y hacer «fixes sobre fixes» para arreglarlo.
Y de eso ya hay mucha tela que cortar. En febrero de 2017, Google activó TLS 1.3 en Chrome 56 y miles de equipos detrás de proxies Blue Coat se quedaron sin Internet. Los aparatos intermedios (los proxies) no toleraban lo nuevo y cortaban la conexión. Google tuvo que recular, camuflando TLS 1.3 para que pareciera 1.2 y negociar con cada fabricante. El peor «fixes sobre fixes» que te puedas imaginar y duele, porque aún no se ha podido quitar eso.
«O lo haces bien, o no haces nada»
Sin embargo, la respuesta a este problema se estandarizó en enero de 2020 como RFC 8701, obra de David Benjamin. La solución muchos la conocen como «gamberra» pero «divertidamente funcional».
¿Por qué? Porque el cliente envía de vez en cuando valores aleatorios sin sentido, con el patrón 0x?A?A, en sus listas de cifrados, versiones y extensiones. Los programas bien hechos los ignoran y siguen adelante (no se caen los servicios, y todo sigue su camino).
Pero si el programa está mal escrito, entonces tu servicio termina muriendo y todo se cae. Si, el propio protocolo de cifrado te puede tumbar un servicio, como el servicio esté mal programado. Cloudflare lo resumió con una imagen perfecta «GREASE es como el WD-40 de Internet». Tal parece que no hay nada más divertido en computación que ver como servicio mueren por estar mal hechos, un placer culposo.
Eso si, OpenSSL tardó en sumarse en esa línea. La petición llevaba abierta desde 2019 y la ha cerrado una contribución externa que sigue el modelo de BoringSSL, la librería de Google. De momento funciona en el lado cliente y ya se puede probar a mano con openssl s_client -grease.
Faro Santander: un punto cero para ver cómo envejece el futuro
AVX-512 al servicio de la era postcuántica
La tercera pieza mira al procesador. Los chips modernos incluyen instrucciones AVX-512 capaces de operar con registros gigantes de 512 bits. Bien usadas, permiten hacer cuatro operaciones criptográficas donde antes cabía una. OpenSSL ya las aprovechaba en varios algoritmos y la 4.1 amplía la cobertura en dos frentes.
El primero es la criptografía postcuántica. ML-DSA, el estándar de firmas digitales que el NIST publicó en agosto de 2024 a partir del esquema CRYSTALS-Dilithium, devora operaciones de la función SHAKE. La alfa estrena un camino AVX-512 que ejecuta cuatro SHAKE en paralelo, además de acelerar las transformadas matemáticas del algoritmo en AVX2 y llevar optimizaciones equivalentes a PowerPC y mainframes s390x.
El segundo frente es más terrenal. El descifrado AES-CBC, todavía omnipresente en redes privadas y sistemas heredados, también recibe su ración de AVX-512.
Qué significa esto para tus equipos. Cada conexión segura negocia claves, verifica firmas y cifra datos, y todo eso cuesta CPU. En un servidor con miles de conexiones por segundo, abaratar esas operaciones se traduce en menos latencia, más conexiones por máquina y menos factura eléctrica. En tu portátil, en handshakes que ni notas, o bueno, quizás un poco en el subidón de temperatura, ya que AVX-512 es como echar gasolina al fuego, hace que todo explote y arda.
Hora de tirar lastre
Como toda versión mayor, OpenSSL 4.1 deja cadáveres. En esta versión, desaparecen los objetivos de compilación para Itanium en Windows y para Windows CE, dos plataformas que pertenecen al museo de maravillas paleolíticas de la computación. Se eliminan las opciones de configuración no-ecdsa y no-ecdh, que en realidad no desactivaban nada y solo generaban confusión. Ahora hay que usar no-ec para prescindir de la curva elíptica, aunque no es la mejor idea, a menos que quieras renunciar a algunos de los mejores algoritmos de seguridad para Internet.
Pero así como se deja lastre, caen nuevas cosas, algunas de ellas, algo exóticas. El mejor ejemplo es el soporte inicial de Elbrus 2000, el procesador ruso hecho para administración y defensa. Resulta curioso eso, porque los Elbrus 2000 son hechos en Taiwan (por TSMC), ya que Rusia no tiene capacidad para generar nada más avanzado de los 90 nm, tecnología de hace 25 años.
Además, la 4.1 promete soporte para KDF de IKEv2, el mecanismo de derivación de claves de las VPN IPsec, más una corrección en la verificación de certificados DSA con SHA-384 y SHA-512. En todo caso, habrá que esperar a la versión final para instalar nada, pero la dirección es inequívoca. Internet también se parchea a sí mismo.