OpenSSL 4.1 trae DTLS 1.3 y le he tirado un paquete adrede

«DTLSv1_listen:unsupported ssl version». Es lo que me contestó OpenSSL 4.1.0 la primera vez que le pedí DTLS 1.3 con -listen, la opción de s_server que espera un ClientHello con cookie antes de conectar. Y tenía razón: la documentación nueva avisa de que esa función no sirve para la versión 1.3.

OpenSSL publicó la 4.1.0 el viernes 23 de octubre, y lo más gordo que trae es DTLS 1.3, el TLS para UDP de la RFC 9147. La he compilado aparte, sin tocar la del sistema, y he medido en 127.0.0.1 cuánto pesa el saludo, qué pasa con -listen y cuánto cuesta perder un datagrama.

Lo Probado es del 27 de octubre de 2026, entre las 06:11 y las 07:10 UTC, en un Ubuntu 24.04 x86-64 de ocho hilos con carga de fondo. Las notas de la versión, la RFC, las incidencias abiertas y los trozos de código que cito son Revisado: leídos, no ejecutados (así los distingo).

Qué trae la 4.1

Según las notas de la versión, publicadas a las 12:23 UTC, con DTLS 1.3 llegan GREASE (RFC 8701), DTLS en la API de listener (SSL_new_listener) y la KDF de IKEv2.

También trae optimizaciones de ML-KEM y ML-DSA para ppc64le y de ML-DSA y del descifrado AES-CBC (con AVX-512 y VAES) para x86-64. En el registro de cambios, DTLS 1.3 va a nombre de Frederik Wedel-Heinen y Ryan Hooper.

Dónde no está todavía

Es una versión sin soporte largo, y la página de descargas le pone fin de vida en noviembre de 2027. La de soporte largo es la 3.5, hasta el 8 de abril de 2030.

Lo que falta en esa lista está fuera de soporte, y la 3.0 de Ubuntu 24.04 falta. La sigue parcheando Canonical: el paquete del 29 de septiembre trae, según su changelog, el arreglo de CVE-2026-84782, un fallo de gravedad alta en la retransmisión de DTLS que OpenSSL publicó ese mismo día.

Hoy, para tener DTLS 1.3 en un Ubuntu, toca compilar. Para probarlo me vale.

Los cuatro fallos que reconoce la nota

En producción no la pondría todavía, y el motivo lo da la propia nota de la versión, que reconoce cuatro fallos conocidos de DTLS:

• #33242: un servidor DTLS 1.3 puede abortar el saludo con unexpected_message si el cliente confirma con un ACK todo o parte del primer vuelo del servidor antes de contestar. Según la nota, puede pasar tras una pérdida o mientras el cliente prepara su respuesta de autenticación.
• #32878: al recibir un KeyUpdate se vacía la cola de reenvío de lo que va después del saludo, y un NewSessionTicket perdido ya no se repite. Es el único para el que la nota anuncia arreglo. En la incidencia, quien la abrió describe un efecto peor: con un KeyUpdate perdido, los datos del cliente dejan de llegar al servidor durante el resto de la conexión, y ninguno de los dos da error.
• #33277: en una conexión aceptada por el listener DTLS, un fallo permanente de recepción sale como SSL_ERROR_WANT_READ, como si bastara con volver a leer.
• #33278: en esas mismas conexiones, en modo no bloqueante, una escritura que solo había que repetir sale como SSL_ERROR_SYSCALL en vez de SSL_ERROR_WANT_WRITE, y quien lo trate como fatal cierra una conexión que funcionaba.

Compilarla sin tocar la del sistema

Como con Python 3.15, todo va a una carpeta propia y sin make install. El único riesgo real es confundir binarios: el de la 4.1 se queda en ~/openssl41/openssl-4.1.0/apps/openssl y no entra en el PATH. Antes de compilar, la suma y la firma:

# Todo en una carpeta propia: sin sudo y sin tocar la OpenSSL del sistema
mkdir -p ~/openssl41 && cd ~/openssl41
V=openssl-4.1.0
U=https://github.com/openssl/openssl/releases/download/$V
curl -sSfL -O $U/$V.tar.gz -O $U/$V.tar.gz.sha256 -O $U/$V.tar.gz.asc
sha256sum -c $V.tar.gz.sha256

# La firma, con las claves de openssl-library.org en un anillo aparte
export GNUPGHOME=$PWD/gnupg && mkdir -p -m 700 $GNUPGHOME
curl -sSfO https://openssl-library.org/source/pubkeys.asc
gpg --batch --import pubkeys.asc 2>/dev/null
gpg --batch --verify $V.tar.gz.asc $V.tar.gz 2>&1 | grep -E 'Good|Primary'

# Sin librerías compartidas: el binario no carga ni pisa la libssl del sistema
tar xzf $V.tar.gz && cd $V
# OPENSSLDIR dentro de la carpeta: así no lee ningún openssl.cnf de /usr/local/ssl
./Configure --prefix=$HOME/openssl41/inst --openssldir=$HOME/openssl41/inst/ssl \
  no-shared no-tests enable-ssl-trace >/dev/null
nice -n 19 make -j3 build_programs >/dev/null 2>&1
./apps/openssl version

# openssl-4.1.0.tar.gz: OK
# gpg: Good signature from "OpenSSL <[email protected]>" [unknown]
# Primary key fingerprint: B146 647E 45A7 B339 47AB  226B 2A2C 87D1 6169 2D40
# OpenSSL 4.1.0 23 Oct 2026 (Library: OpenSSL 4.1.0 23 Oct 2026)

La huella B146 647E… es la que la página de descargas da como ancla para las versiones actuales. La clave anterior, BA54 73A2…, certificó la nueva el 1 de junio, y esa firma viaja en pubkeys.asc, no en los servidores de claves. Descarga y compilación juntas tardaron menos de tres minutos, con nice y tres trabajos.

De paso probé lo que se ha ido: ./Configure no-ecdsa ya contesta «Unsupported options: no-ecdsa». La nota explica que esa opción y no-ecdh «did not really disable the implementations» y manda a no-ec, que quita toda la curva elíptica.

El primer saludo, con ML-KEM dentro

Un certificado de usar y tirar, un servidor en 127.0.0.1 y un cliente con -trace, que enseña los mensajes del saludo:

cd ~/openssl41/openssl-4.1.0
O=./apps/openssl
# req necesita un openssl.cnf: el que trae el propio código
export OPENSSL_CONF=$PWD/apps/openssl.cnf
# Certificado de usar y tirar, válido dos días
$O req -x509 -newkey ec -pkeyopt ec_paramgen_curve:P-256 -noenc -days 2 \
  -keyout k.pem -out c.pem -subj /CN=localhost 2>/dev/null

# Servidor DTLS solo en 127.0.0.1; -naccept 1 lo cierra tras un cliente
sleep 10 | timeout 15 $O s_server -dtls -accept 127.0.0.1:4433 \
  -cert c.pem -key k.pem -naccept 1 >/dev/null 2>&1 &
sleep 1
echo hola | $O s_client -dtls -connect 127.0.0.1:4433 -trace 2>&1 \
  | grep -E '^New,|NamedGroup|cookie_ext|handshake has read' | sort | uniq -c
wait

#       2             NamedGroup: ecdh_x25519 (29)
#       3             NamedGroup: X25519MLKEM768 (4588)
#       2         extension_type=cookie_ext(44), length=122
#       1 New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
#       1 SSL handshake has read 2215 bytes and written 3286 bytes

Dos 4.1 acuerdan la 1.3 sin pedírsela, solo con -dtls («cualquier versión de DTLS»). El cliente manda dos claves, X25519MLKEM768 (el híbrido poscuántico) y X25519, como en TLS desde la 3.5.0 según el registro de cambios. La primera sale tres veces: en los dos ClientHello y en el ServerHello, donde el servidor la elige.

El segundo ClientHello lo pide el servidor. Antes de nada contesta con un HelloRetryRequest que no pide otra clave (no lleva key_share) y trae, junto a la versión, una extensión de cookie de 122 bytes para validar la dirección de origen. El cliente la devuelve, y por eso cookie_ext aparece dos veces.

Cuánto pesa el saludo

s_client ya cuenta los bytes que lee y escribe durante el saludo. Fijo el MTU en 1400, para que los trozos se parezcan a los de una red normal, y comparo tres clientes contra el mismo servidor:

cd ~/openssl41/openssl-4.1.0
O=./apps/openssl
# Mismo servidor, tres clientes; MTU de 1400 para no trocear de más
for c in "-dtls1_2" "-dtls1_3 -groups X25519" "-dtls1_3"; do
  sleep 5 | timeout 10 $O s_server -dtls -mtu 1400 -accept 127.0.0.1:4433 \
    -cert c.pem -key k.pem -naccept 1 >/dev/null 2>&1 &
  sleep 1
  echo hola | $O s_client $c -mtu 1400 -connect 127.0.0.1:4433 2>&1 \
    | grep -E 'handshake has read' | sed "s/^/$c: /"
  wait
done

# -dtls1_2: SSL handshake has read 957 bytes and written 573 bytes
# -dtls1_3 -groups X25519: SSL handshake has read 997 bytes and written 648 bytes
# -dtls1_3: SSL handshake has read 2090 bytes and written 3178 bytes

DTLS 1.3 por sí solo apenas pesa más que la 1.2. Lo que multiplica el saludo por más de tres es ML-KEM: el ServerHello pasa de 86 bytes a 1.174, y el ClientHello, de 195 a 1.435, ya no cabe en un datagrama de 1400.

El HelloRetryRequest obliga a repetir el ClientHello, así que el cliente lo manda dos veces: de ahí sus 3.178 bytes. Mi certificado es mínimo; con una cadena real, lo que lee el cliente sube. Por UDP, cada datagrama de más es otro que se puede perder, y dos apartados más abajo se ve lo que cuesta.

-groups X25519 lo deja casi como DTLS 1.2, pero renuncia al intercambio poscuántico. Yo no lo quitaría sin una razón medida en la red donde se vaya a usar.

Mi opinión, no una recomendación del proyecto. ML-KEM es el FIPS 203

La trampa de -listen

Vuelvo al error del principio, ahora con las dos variantes y un cliente que ofrece cualquier versión:

cd ~/openssl41/openssl-4.1.0
O=./apps/openssl
for s in "-dtls1_3 -listen" "-dtls -listen"; do
  sleep 6 | timeout 8 $O s_server $s -accept 127.0.0.1:4433 \
    -cert c.pem -key k.pem -naccept 1 2>&1 | grep -E 'error' &
  sleep 1
  echo hola | timeout 5 $O s_client -dtls -connect 127.0.0.1:4433 2>&1 \
    | grep -E '^New,' | sed "s/^/s_server $s: /"
  wait
done

# 400776719F750000:error:0A000103:SSL routines:DTLSv1_listen:unsupported ssl version:ssl/d1_lib.c:702:
# s_server -dtls1_3 -listen: New, (NONE), Cipher is (NONE)
# s_server -dtls -listen: New, TLSv1.2, Cipher is ECDHE-ECDSA-AES256-GCM-SHA384

Con -dtls1_3 -listen no hay conexión. Con -dtls -listen sí, pero un cliente 4.1 que ofrece la 1.3 acaba en DTLS 1.2 y nadie avisa. La guía lo deja escrito:

DTLSv1_listen(3) only supports DTLS 1.0/1.2 with HelloVerifyRequest and cannot be used with DTLSv1.3.

ossl-guide-dtlsv13(7), OpenSSL 4.1.0

Mi lectura: una aplicación montada sobre DTLSv1_listen() no gana DTLS 1.3 por actualizar la biblioteca. Tiene que pasarse a SSL_new_listener(), y justo ahí viven dos de los cuatro fallos conocidos. Esos dos no son solo de la 1.3: las pruebas de quien los abrió usan DTLS 1.2, y en la #33278 aclara que afecta a cualquier DTLS.

Un paquete perdido, adrede

Para ver qué pasa cuando se pierde un datagrama he escrito un relé UDP de veinticuatro líneas. Se pone entre cliente y servidor, no descifra nada, apunta cada datagrama y tira una sola vez el que se le pida del servidor al cliente. Lo guardo como ~/openssl41/perdida.py:

#!/usr/bin/env python3
# Relé UDP en 127.0.0.1 que tira UNA vez el datagrama n-ésimo del servidor al cliente.
# Uso: perdida.py PUERTO_CLIENTES PUERTO_SERVIDOR N
import select, socket, sys, time
escucha, servidor, tirar = int(sys.argv[1]), int(sys.argv[2]), int(sys.argv[3])
a = socket.socket(socket.AF_INET, socket.SOCK_DGRAM); a.bind(("127.0.0.1", escucha))
b = socket.socket(socket.AF_INET, socket.SOCK_DGRAM); b.bind(("127.0.0.1", 0))
cliente, n, t0, fin = None, 0, None, time.monotonic() + 8
while time.monotonic() < fin:
    for s in select.select([a, b], [], [], 0.05)[0]:
        d, origen = s.recvfrom(65535)
        t0 = t0 or time.monotonic()
        # Primer byte 001xxxxx: cabecera unificada de DTLS 1.3, ya cifrado
        tipo = "cifrado" if d[0] & 0xE0 == 0x20 else {22: "saludo", 21: "alerta"}.get(d[0], hex(d[0]))
        if s is a:
            cliente, sentido = origen, "cliente  -> servidor"
            b.sendto(d, ("127.0.0.1", servidor))
        else:
            n += 1
            sentido = "servidor -> cliente "
            if n != tirar:
                a.sendto(d, cliente)
        nota = "   <- TIRADO" if s is b and n == tirar else ""
        print(f"{(time.monotonic() - t0) * 1000:7.1f} ms  {sentido} {len(d):4d} B {tipo}{nota}", flush=True)

El servidor, con MTU 400, manda primero el HelloRetryRequest y luego su vuelo en seis datagramas. Tiro el sexto que sale del servidor, el penúltimo del vuelo, que ya va cifrado:

cd ~/openssl41/openssl-4.1.0
O=./apps/openssl
# Servidor en 4433, relé en 4434; MTU de 400 para que el vuelo vaya en varios datagramas
sleep 9 | timeout 10 $O s_server -dtls1_3 -mtu 400 -accept 127.0.0.1:4433 \
  -cert c.pem -key k.pem -naccept 1 >/dev/null 2>&1 &
timeout 10 python3 -I ~/openssl41/perdida.py 4434 4433 6 > rele.txt &
sleep 1
/usr/bin/time -f "s_client: %e s" sh -c "echo hola | $O s_client -dtls1_3 -mtu 400 \
  -connect 127.0.0.1:4434 2>&1 | grep -E '^New,'"
wait
cat rele.txt

# New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
# s_client: 1.07 s
# […] once datagramas: ClientHello, HelloRetryRequest y ClientHello con cookie
#     1.2 ms  servidor -> cliente   371 B saludo
#     1.3 ms  servidor -> cliente   371 B saludo
#     1.3 ms  servidor -> cliente   371 B saludo
#     5.1 ms  servidor -> cliente   372 B saludo
#     5.1 ms  servidor -> cliente   362 B cifrado   <- TIRADO
#     5.2 ms  servidor -> cliente    82 B cifrado
#  1057.0 ms  servidor -> cliente   371 B saludo
#  1057.6 ms  servidor -> cliente   371 B saludo
#  1057.6 ms  servidor -> cliente   371 B saludo
#  1057.7 ms  servidor -> cliente   161 B saludo
#  1058.9 ms  servidor -> cliente    36 B cifrado
#  1059.0 ms  servidor -> cliente   372 B cifrado
#  1061.6 ms  servidor -> cliente    56 B cifrado
#  1061.6 ms  servidor -> cliente   109 B cifrado
#  1061.6 ms  servidor -> cliente    82 B cifrado
#  1062.9 ms  cliente  -> servidor   82 B cifrado
#  1063.0 ms  servidor -> cliente    40 B cifrado
# […] tiques de sesión, «hola» y cierre

El saludo termina, pero s_client tarda 1,07 segundos (1,04 al repetirlo). Entre la pérdida y la repetición, a los 1.057 ms, el cliente no manda nada. El servidor tampoco sabe qué se ha perdido y repite el vuelo entero en nueve datagramas, también lo que ya había llegado.

Con DTLS 1.2 en las dos puntas, tirando también un datagrama del vuelo del servidor (allí, el primero después del HelloVerifyRequest), tarda 1,06 segundos (1,02 al repetirlo). Ahí la 1.3 no gana nada.

Lo que pide la RFC y lo que hace la 4.1

When an implementation detects a disruption in the receipt of the current incoming flight, it SHOULD generate an ACK that covers the messages from that flight which it has received and processed so far.

RFC 9147, sección 7.1, que lo recomienda al recibir un trozo fuera de orden y al tener parte de un vuelo sin que llegue el resto

El cliente de la 4.1 no lo hizo en ninguna de mis ocho pruebas: en todas se quedó callado un segundo. En cinco ya tenía el ServerHello completo y perdí el penúltimo o el último datagrama del vuelo. En las otras tres perdí un trozo del ServerHello, y al cabo del segundo repitió el cliente, con su ClientHello entero.

Por qué la #33242 no salta entre dos OpenSSL

La propia incidencia lo explica, y en el código de la 4.1 se ve: en ssl/ssl_local.h, dtls_msg_needs_ack() solo pide ACK, de lo que manda el servidor, para NewSessionTicket y KeyUpdate. Un cliente OpenSSL nunca confirma el vuelo del saludo, que es justo lo que hace abortar al servidor.

La abrió un agente de IA mientras probaba dimpl, una implementación en Rust, y así lo avisa en la primera línea. OpenSSL la ha clasificado como fallo y la lleva en la nota de la versión.

De dónde sale el segundo de espera

El segundo de espera es el valor por defecto de OpenSSL, que se dobla en cada reintento hasta 60 segundos (está en ssl/d1_lib.c y en la página de DTLS_set_timer_cb).

La RFC pide lo mismo, 1000 ms, si no se sabe nada del tiempo de ida y vuelta; para DTLS-SRTP, que va en tiempo real, recomienda 400. Una aplicación lo cambia con DTLS_set_timer_cb(); eso lo he leído, no lo he probado.

Con la OpenSSL de Ubuntu 24.04 al otro lado

En un Ubuntu 24.04, lo que la 4.1 tiene enfrente es la 3.0.13 del sistema, y eso es lo que llama el bloque. Yo usé la del paquete 3.0.13-0ubuntu3.16, desempaquetado de su .deb sin instalarlo y puesto delante en el PATH:

cd ~/openssl41/openssl-4.1.0
O=./apps/openssl
openssl version   # la del sistema: en Ubuntu 24.04, 3.0.13
openssl s_client -dtls1_3 2>&1 | head -1
# Servidor 4.1 y cliente de Ubuntu
sleep 5 | timeout 8 $O s_server -dtls -accept 127.0.0.1:4433 \
  -cert c.pem -key k.pem -naccept 1 >/dev/null 2>&1 &
sleep 1
echo hola | openssl s_client -dtls -connect 127.0.0.1:4433 2>&1 | grep -E '^New,'
wait
# GREASE: cliente 4.1 con -grease contra un servidor TLS de Ubuntu (TCP)
sleep 5 | timeout 8 openssl s_server -accept 127.0.0.1:4433 \
  -cert c.pem -key k.pem -naccept 1 >/dev/null 2>&1 &
sleep 1
echo hola | $O s_client -grease -trace -connect 127.0.0.1:4433 > grease.txt 2>&1
wait
awk '/Received TLS Record/{exit} /UNKNOWN/' grease.txt   # solo el ClientHello
grep '^New,' grease.txt

# OpenSSL 3.0.13 30 Jan 2024 (Library: OpenSSL 3.0.13 30 Jan 2024)
# s_client: Unknown option: -dtls1_3
# New, TLSv1.2, Cipher is ECDHE-ECDSA-AES256-GCM-SHA384
#         {0xCA, 0xCA} UNKNOWN
#           UNKNOWN (35466)
#           UNKNOWN (0xfafa)
#           UNKNOWN (39578)
#             NamedGroup: UNKNOWN (35466)
#         extension_type=UNKNOWN(47802), length=0
#         extension_type=UNKNOWN(51914), length=1
# New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384

La 3.0.13 no conoce -dtls1_3, y con un servidor 4.1 las dos se quedan en DTLS 1.2. Al revés, cliente 4.1 y servidor de Ubuntu, también 1.2: lo probé aparte, y el ClientHello de 1,4 KB con ML-KEM no le molestó.

GREASE no molesta a la 3.0.13

Las siete líneas UNKNOWN son los valores GREASE que mete -grease en el ClientHello, con la forma 0x?A?A que reserva la RFC 8701: uno por lista (suites, grupos, firmas, versiones y claves) y dos extensiones, una vacía y otra de un byte. El servidor de Ubuntu los ignoró y acordó TLS 1.3; en DTLS, 1.2.

Comprobación

Compruebo que el binario es la 4.1, que trae los grupos con ML-KEM y que no ha quedado nada escuchando:

cd ~/openssl41/openssl-4.1.0
./apps/openssl version
# Grupos con ML-KEM, puros e híbridos, que trae esta compilación
./apps/openssl list -tls-groups | tr ':' '\n' | grep MLKEM | paste -sd' '
# Que no quede nada escuchando en el puerto de pruebas (0 = limpio)
ss -lun | grep -c ':4433 '

# OpenSSL 4.1.0 23 Oct 2026 (Library: OpenSSL 4.1.0 23 Oct 2026)
# MLKEM512 MLKEM768 MLKEM1024 SecP256r1MLKEM768 X25519MLKEM768 SecP384r1MLKEM1024 curveSM2MLKEM768
# 0

Vuelta atrás

En el sistema no hay nada que deshacer, porque no se ha instalado nada. Si algún servidor de prueba se ha quedado vivo, se mata, y después se borra la carpeta:

pkill -f '^\./apps/openssl s_server' ; cd ~ && rm -rf ~/openssl41

Qué no he probado

• Clientes de otras bibliotecas (BoringSSL, Pion, dimpl, wolfSSL, GnuTLS): sin ellos no he visto el aborto de la #33242.
• La API de listener desde C: solo he usado s_server. La #33277, la #33278 y la #32878 se quedan sin reproducir.
• Una red real: todo ha ido por 127.0.0.1, con un MTU fijado a mano y una pérdida provocada.
• Las optimizaciones de AVX-512 y VAES: la CPU de la prueba no tiene ninguna de las dos, según /proc/cpuinfo. Tampoco ARM ni ppc64le.
• Connection ID, que la guía da por no soportado en DTLS 1.3, ni DTLS sobre SCTP, que según la guía baja a 1.2.
• Instalar la 4.1 encima de la del sistema. En un Ubuntu 24.04 no pienso hacerlo.

La parte de certificados ya la toqué con la raíz retirada de eMudhra; el resto de guías de red está en Servidores, redes y almacenamiento.

Imagen destacada: una Raspberry Pi 4 sobre un conmutador de red, foto de RAIL P (RAIL.PHOTOGRAPHY), CC0, vía Wikimedia Commons. Es una foto de contexto: no es mi máquina y no sale en las pruebas.