OpenSSL 4.1.0: DTLS 1.3 y criptografía post-cuántica

DTLS 1.3, el protocolo que cifra el tráfico UDP de videollamadas, VPN y dispositivos IoT, ya tiene soporte completo en OpenSSL 4.1.0 bajo el RFC 9147. Para una startup que corre su propia infraestructura, la actualización no es un detalle de mantenimiento: llega con operaciones post-cuánticas más rápidas y con tres cambios que rompen compatibilidad con builds y dependencias actuales. Y trae cuatro bugs conocidos de DTLS que conviene leer antes de tocar producción.

DTLS 1.3: qué cambia en el tráfico que viaja por UDP

DTLS (Datagram Transport Layer Security) cifra conexiones sobre UDP en lugar de TCP: el transporte que usan videollamadas, VPN y dispositivos IoT, donde los paquetes pueden llegar tarde o fuera de orden. La versión 1.3, definida en el RFC 9147, lleva ese tráfico al mismo baseline de seguridad que TLS 1.3, cerrando la brecha que arrastraban los despliegues DTLS en forward secrecy y overhead de handshake, según el análisis que Help Net Security publicó del build alpha de esta versión.

El release suma además GREASE según el RFC 8701 —un mecanismo que evita que clientes y servidores TLS se rompan ante valores de extensión que no reconocen—, soporte DTLS en la API de listener SSL, soporte para la función de derivación de claves IKEv2 que se usa en negociaciones de VPN, y soporte inicial para la arquitectura Elbrus2000 (e2k).

Para un founder que construye sobre WebRTC, VoIP, gaming en tiempo real o telemetría de dispositivos, esto es lo relevante: la capa de cifrado que usan esos productos deja de estar un escalón por detrás de la que usan los servicios web.

Criptografía post-cuántica: ahora el foco es el costo, no el algoritmo

Las notas de la versión listan operaciones NTT optimizadas de ML-DSA y ML-KEM en ppc64le, operaciones ML-DSA optimizadas en x86_64, instrucciones AVX-512 para las operaciones SHAKE x4 de las que depende ML-DSA en x86_64, y optimizaciones AVX-512 y VAES para el descifrado AES-CBC en x86_64.

Nada de esto cambia qué hacen los algoritmos. Cambia cuánto cuesta ejecutarlos, un punto que gana peso a medida que las organizaciones empiezan a migrar sistemas productivos a intercambio de claves y firmas post-cuánticas, como señaló Help Net Security al cubrir el build alpha.

El costo tiene dos frentes. El primero es el tamaño: según TechTimes, una clave pública ML-KEM ronda los 1.184 bytes frente a los 32 bytes de una clave de curva elíptica X25519, y una clave pública ML-DSA llega a 1.312 bytes frente a unos 33 bytes de ECDSA. El segundo es la latencia: la misma cobertura cita investigación sobre TLS post-cuántico en infraestructura de trading que midió un incremento cercano al 23% en el tiempo de establecimiento de conexión, de unos 24,7 milisegundos a 30,4 milisegundos.

Traducido a un producto: más bytes en el handshake, más espacio en PKI, más peso en las cadenas de certificados y más tiempo en cada conexión nueva. Para una app de consumo probablemente sea invisible. Para pagos, trading o cualquier sistema sensible a la latencia, es una variable que se mide y no se asume.

Los cambios que rompen compatibilidad antes de actualizar

Esta es la parte que conviene leer con el pipeline de build abierto:

• tsget cambió de dependencia. La utilidad de timestamps ahora usa Net::Curl::Easy (de la distribución Net-Curl de CPAN) en lugar de WWW::Curl::Easy, que está abandonada. Si tu proceso de firma de timestamps usa tsget, instala la nueva dependencia antes de actualizar o el flujo se rompe.
• Se eliminaron dos targets de Windows. Los objetivos VC-WIN64I (Windows on Itanium) y VC-CE (Windows CE) salieron de Configurations. Si compilas para esas plataformas, te quedas sin soporte en esta versión.
• Configure ya no acepta no-ecdsa ni no-ecdh. El motivo que da el proyecto es directo: esas opciones nunca desactivaban realmente las implementaciones. Para apagar el soporte de curvas elípticas hay que usar no-ec.

En el otro extremo, se agregaron los targets VC-WIN32-MSVC2013 y VC-WIN64A-MSVC2013, pensados para cubrir los huecos de soporte de C99 que arrastra MSVC 2013.

Los cuatro bugs conocidos de DTLS 1.3

El proyecto documentó cuatro problemas abiertos, todos en la parte nueva del release. Es la razón por la que una adopción sensata empieza en staging y no en producción:

• Issue #32878: cuando se recibe un KeyUpdate de DTLS 1.3, los demás registros post-handshake pendientes se descartan del buffer de retransmisión. Un NewSessionTicket que esperaba ACK ya no se retransmite si el envío original se pierde. Hay un fix en camino para una versión futura.
• Issue #33277: una falla permanente de recepción en un listener DTLS puede reportarse como SSL_ERROR_WANT_READ en una conexión aceptada. El polling y los accept posteriores pueden no reportar el error, y la aplicación sigue esperando después de una falla permanente.
• Issue #33278: una falla de escritura reintentable en una conexión no bloqueante aceptada desde un listener DTLS puede reportarse como SSL_ERROR_SYSCALL en vez de SSL_ERROR_WANT_WRITE. Una app que trata ese resultado como fatal cierra una conexión que todavía era usable.
• Issue #33242: los servidores DTLS 1.3 pueden abortar handshakes con una alerta unexpected_message cuando el cliente reconoce parte o todo el primer vuelo del servidor antes de enviar su respuesta. Puede pasar tras pérdida de paquetes o mientras el cliente prepara su respuesta de autenticación.

¿Por qué la criptografía post-cuántica dejó de ser un tema de 2030?

Porque la presión regulatoria y de procurement ya es medible. Según eWeek, el reporte de capacidades PQC de MITRE correspondiente a septiembre de 2026 —con evidencia recolectada en julio de 2026— encontró que el establecimiento de claves post-cuántico llegó a nivel Integration en cinco de seis categorías aplicables de tecnología empresarial, mientras que las firmas digitales solo alcanzaron ese nivel en dos de ocho categorías. Ninguna categoría llegó a Validated Integration, el nivel más alto. Y no se encontró evidencia de TPMs de hardware post-cuánticos disponibles comercialmente a julio de 2026.

Los plazos federales de Estados Unidos, también vía eWeek, separan ambos frentes: 31 de diciembre de 2030 para establecimiento de claves y 31 de diciembre de 2031 para firmas en sistemas federales de alto valor.

El lado del mercado no va mucho más rápido. La encuesta Quantum Readiness Outlook 2026 de DigiCert, citada por TechTimes sobre 1.001 responsables de IT y ciberseguridad en Estados Unidos, Reino Unido y Australia, encontró que el 87% de las organizaciones está planificando, probando o implementando iniciativas PQC, pero solo el 7% desplegó criptografía quantum-safe o híbrida en la mayoría de sus certificados digitales. Ese mismo medio recuerda que el 21 de septiembre de 2026 los certificados FIPS 140-2 restantes pasaron a estado Historical, y que solo los módulos validados bajo FIPS 140-3 se aceptan para nuevas compras federales.

¿Qué significa esto para tu startup?

La buena noticia es que casi nada de esto exige una decisión hoy mismo. Lo que sí exige es saber dónde estás parado:

• Haz el inventario criptográfico primero. Antes de tocar una versión, responde tres preguntas: qué algoritmos usas, dónde viven tus certificados y claves, y de qué proveedores dependes para TLS, HSM o PKI. Sin ese mapa, migrar es adivinar.
• Si usas UDP, prueba 4.1.0 en staging, no en producción. WebRTC, VoIP, VPN propia, gaming o telemetría IoT son los casos donde DTLS 1.3 aporta de verdad. Prueba los cuatro escenarios de bug documentados antes de considerar el salto.
• Presupuesta el tamaño y mide la latencia. Si vas a adoptar ML-KEM o ML-DSA, calcula el impacto en ancho de banda de handshake, almacenamiento de certificados y latencia de conexión. Los números de TechTimes marcan el orden de magnitud.
• Exige a tus proveedores respuestas concretas. Algoritmos soportados, roadmap de producto, estado de validación FIPS 140-3, condiciones de upgrade y fechas de fin de soporte. Un proveedor que no puede responder esto es una dependencia criptográfica desconocida en tu riesgo.
• Diseña para crypto-agility, no para un algoritmo. Poder cambiar el algoritmo en la capa de protocolo sin reescribir aplicaciones vale más que haber desplegado ML-KEM una vez.

Conclusión

OpenSSL 4.1.0 es un release de features con dos historias dentro. La primera es técnica y concreta: DTLS 1.3 por fin alcanza el baseline de TLS 1.3 para el tráfico UDP, con optimizaciones post-cuánticas que abaratan correr ML-DSA y ML-KEM. La segunda es de timing: el ecosistema post-cuántico se está moviendo más rápido de lo que sugiere la fecha de 2030, y las empresas que van a quedar expuestas son las que no hicieron el inventario a tiempo.

Para una startup, el movimiento correcto es el mismo en ambos casos: entender qué criptografía corre hoy en tu producto, probar la nueva versión donde no haya usuarios de por medio, y no apurar producción mientras los cuatro bugs de DTLS sigan abiertos. La actualización no es urgente; la ignorancia sobre tu propia infraestructura sí lo es.

Fuentes

• OpenSSL 4.1.0 — release notes (fuente original)
• Help Net Security — OpenSSL's new alpha build speeds up post-quantum crypto
• eWeek — MITRE Reports Post-Quantum Signature Gaps Ahead of Federal Deadline
• TechTimes — Banks Can Finish Post-Quantum Migration and Still Be Exposed