Medí 320 sitios chilenos: la mitad ya usa criptografía post-cuántica, y casi ninguno lo decidió

Hace un día publiqué que había armado un handshake completamente post-cuántico en mi propio servidor. Me quedó una pregunta incómoda: muy bonito en un portátil, pero ¿quién lo tiene de verdad? No en una demo, no en el blog de un fabricante. En los sitios donde un chileno mete su clave todos los días.

Así que lo medí. Tomé los 320 dominios .cl mejor rankeados y le pregunté a cada uno, uno por uno, con qué criptografía acepta acordar la llave de la conversación. La respuesta corta es que la mitad ya usa post-cuántica. La respuesta larga es más interesante, porque casi ninguno de ellos lo decidió.

Qué se está reemplazando, y por qué corre el reloj

Cuando abres una página con candado ocurren dos cosas antes del primer byte útil. Las dos usan criptografía, pero resuelven problemas distintos y tienen relojes distintos.

La primera es acordar una llave secreta hablando por un canal que cualquiera puede leer. Es el intercambio de claves, y es lo que hace que el resto de la conversación viaje cifrada.

La segunda es demostrar quién es cada uno, con un certificado firmado por alguien en quien tu navegador confía.

Un computador cuántico con capacidad suficiente rompe las dos. Pero solo una de las dos tiene urgencia hoy, y la razón es la que hace que este tema no se pueda posponer.

Cifrar es meter la carta en un sobre lacrado. Alguien puede robarse el sobre esta tarde, guardarlo en una bodega y esperar. El día que exista la máquina, lo abre, y adentro está lo que enviaste hoy. Se le llama cosechar ahora, descifrar después, y es la razón de que el intercambio de claves corra contra un reloj que ya está andando.

Firmar es distinto. Es el guardia que mira tu cédula en la puerta: solo tiene que aguantar el segundo que dura la revisión. Nadie puede volver en 2035 a falsificar la cédula que mostraste hoy, porque hoy ya te dejaron entrar.

Por eso el ecosistema arregló primero el sobre y dejó la cédula para después. No fue un descuido: fue el orden correcto. Y lo que medí en estos 320 sitios es exactamente esa primera mitad, la urgente: el intercambio de claves.

$ openssl s_client -connect efraingaray.com:443 -servername efraingaray.com \
    -groups X25519MLKEM768 -msg -state </dev/null

SSL_connect:before SSL initialization
SSL_connect:SSLv3/TLS write client hello
>>> TLS 1.3, Handshake [length 05cd], ClientHello
SSL_connect:SSLv3/TLS read server hello
<<< TLS 1.3, Handshake [length 04ba], ServerHello
<<< TLS 1.3, ChangeCipherSpec [length 0001]
SSL_connect:TLSv1.3 read encrypted extensions
<<< TLS 1.3, Handshake [length 000a], EncryptedExtensions
<<< TLS 1.3, Handshake [length 0d58], Certificate
depth=3 C=US, O=Internet Security Research Group, CN=ISRG Root X2
verify return:1
depth=2 C=US, O=ISRG, CN=Root YE
verify return:1
depth=1 C=US, O=Let's Encrypt, CN=YE2
verify return:1
depth=0 CN=efraingaray.com
verify return:1
SSL_connect:SSLv3/TLS read server certificate
<<< TLS 1.3, Handshake [length 004f], CertificateVerify
SSL_connect:TLSv1.3 read server certificate verify
<<< TLS 1.3, Handshake [length 0024], Finished
SSL_connect:SSLv3/TLS read finished
>>> TLS 1.3, ChangeCipherSpec [length 0001]
>>> TLS 1.3, Handshake [length 0024], Finished
SSL_connect:SSLv3/TLS write finished
SSL_connect:SSL negotiation finished successfully
<<< TLS 1.3, Handshake [length 007a], NewSessionTicket

Negotiated TLS1.3 group: X25519MLKEM768
Protocol  : TLSv1.3
Cipher    : TLS_AES_128_GCM_SHA256
Verify return code: 0 (ok)

$ openssl s_client -connect www.sii.cl:443 -servername www.sii.cl \
    -groups X25519MLKEM768 -msg -state </dev/null

SSL_connect:before SSL initialization
>>> TLS 1.3, Handshake [length 05c8], ClientHello
SSL_connect:SSLv3/TLS write client hello
<<< TLS 1.3, Alert [length 0002], fatal handshake_failure
SSL3 alert read:fatal:handshake failure
SSL_connect:error in error
error:0A000410:SSL routines:ssl3_read_bytes:ssl/tls alert handshake failure:
    ssl/record/rec_layer_s3.c:918:SSL alert number 40

Negotiated TLS1.3 group: <NULL>

Cómo lo medí

La idea la copié de Cloudflare, que publicó hoy mismo cómo sondea los servidores de sus clientes cada 24 horas para descubrir con qué saben hablar. La versión casera cabe en una línea:

openssl s_client -groups X25519MLKEM768 -connect bci.cl:443 -servername bci.cl </dev/null

Si el servidor sabe, responde con la llave acordada. Si no sabe, la conexión no se establece, y entonces hay que repetir la pregunta con la lista clásica para saber qué sí habla. Esa segunda pasada es la que separa “no tiene post-cuántico” de “no responde”.

Los 320 dominios salen del ranking Tranco filtrado por .cl, que no es lo mismo que 320 empresas chilenas: ahí dentro hay google.cl, airbnb.cl y adidas.cl. Cada uno se midió con OpenSSL 3.6.3 desde una conexión doméstica en Chile, el 8 de septiembre de 2026.

El tropiezo que casi arruina la muestra

Los primeros resultados decían que Santander, BancoEstado y Scotiabank no soportaban nada. Era falso: esos dominios no resuelven su nombre raíz. Solo existe www. delante. Si escribes santander.cl a secas, no hay dirección IP a la que ir.

Lo mismo con el Banco Central, que ni siquiera tiene bancocentral.cl: su dominio es bcentral.cl. Al final fueron 31 de los 320 los que solo respondieron con www. delante, y entre ellos varios de los sitios más visitados del país. La sonda ahora reintenta antes de rendirse.

El segundo fallo lo encontré revisando los resultados, y es más sutil. Preguntar ofreciendo solo el grupo post-cuántico no es lo que hace un navegador: un navegador manda también una clave clásica de respaldo en el mismo saludo. Un borde que exige esa clave de respaldo responde alert 40 a mi pregunta y post-cuántico al navegador. Eso me dio un falso negativo, minvu.cl, que sí lo tiene. Volví a preguntar por los 160 restantes como pregunta un navegador y solo apareció ese: por eso el número de este artículo es 145 y no 144.

Cuántos sitios chilenos negocian post-cuántico

De los 320 dominios, 304 responden TLS y 16 no respondieron: unos no resuelven, cuatro son servidores DNS del Estado y el resto agotó el tiempo de espera.

De los 304 dominios .cl que respondían TLS el 8 de septiembre de 2026, 145 negocian X25519MLKEM768: el 47,7 %.

Es mejor de lo que esperaba antes de medir, y no significa lo que parece.

Quién lo puso ahí

Al mismo tiempo que la sonda preguntaba por la criptografía, anotaba de quién es la dirección IP que responde. Eso separa dos poblaciones que se ven idénticas desde afuera: el que activó algo, y el que recibió algo.

Ahí está el artículo entero. De los 128 sitios que sirven TLS desde su propia infraestructura, nueve lo tienen. Los otros 136 que aparecen en la columna de los buenos lo recibieron de su borde, sin tener que hacer nada.

Ese 47,7 % no es una decisión de la industria chilena. Es una decisión de Cloudflare, Akamai, Imperva y Fastly, que la aplicaron a sus clientes sin que ninguno tuviera que pedirla.

Una advertencia sobre esta tabla: lo que agrupo no es el CDN, es el dueño de la dirección IP. Amazon y Google mezclan su CDN con máquinas que alguien administra a mano, así que 128 es la cota baja de sitios con infraestructura propia, no un conteo exacto. De los seis en direcciones de Microsoft, uno lo tiene.

Los nueve que sí lo decidieron

Vale la pena nombrarlos, porque son los que sí hicieron algo:

spensiones.cl (Superintendencia de Pensiones), aiep.cl, uahurtado.cl, uft.cl, desis.cl, ibus.cl, creattiva.cl, v2net.cl y tecnoinver.cl.

El primero es el más llamativo. La Superintendencia de Pensiones corre sobre la infraestructura del Ministerio del Interior, el mismo bloque de direcciones donde viven interior.gob.cl, registrocivil.cl y minsal.cl. Esos tres no lo tienen y spensiones.cl sí. Es el mismo proveedor, la misma red: la diferencia está en el software que atiende, no en la red ni en el presupuesto.

El mapa chileno, con nombres

Entre los que ya negocian post-cuántico: Santander, BancoEstado, Scotiabank, Banco de Chile, BCI, Banco Falabella, Banco Ripley, Coopeuch, Consorcio, Transbank, ClaveÚnica, ChileAtiende, la Tesorería General de la República en tgr.gob.cl, el Banco Central, Ripley, Líder, Sodimac, Enel y Aguas Andinas.

Entre los que no: el Servicio de Impuestos Internos, la Comisión para el Mercado Financiero, el Registro Civil, Minsal, Mercado Público, FONASA, SENCE, la Dirección del Trabajo, Entel, Movistar, WOM, Emol, BioBioChile, Diario Financiero, la Universidad de Chile, la UC y NIC Chile, que administra el dominio .cl.

Cuatro nombres que uno esperaría aquí no están en la muestra, porque el ranking Tranco no los tiene o los tiene en otro dominio. Los medí aparte, con el mismo comando y el mismo día: Itaú, Tenpo y falabella.com lo negocian; Comisaría Virtual, VTR y La Tercera, no.

De los 12 dominios .gob.cl de la muestra, 3 lo tienen. Los tres están detrás de un CDN.

Lo que cuesta: cero

La pregunta obvia es qué se paga por esto. ML-KEM manda más bytes que una curva elíptica, y más bytes en el handshake deberían costar tiempo.

Aquí hay una trampa que vale la pena contar, porque caí en ella. Mi primera comparación tomó la mediana de los sitios post-cuánticos (202 ms) contra la de los clásicos (100 ms) y parecía decir que el post-cuántico duplica el tiempo. Ese número no mide nada. Los sitios detrás de un CDN están más cerca del visitante que un servidor en un datacenter chileno: lo que medí fue la distancia, no el algoritmo.

La única comparación válida es cada servidor contra sí mismo. Doce handshakes de cada tipo, alternados para que una congestión pasajera afecte a los dos por igual:

Mediana de la diferencia: −0,1 ms. Peor caso: +2,7 ms.

Es indistinguible de cero, y en cuatro de los ocho el post-cuántico salió más rápido, lo que solo significa que el ruido de la red es mayor que el efecto que buscamos. Esa es la conclusión: el coste está por debajo del ruido.

Cómo activar criptografía post-cuántica en un servidor

Aquí viene la parte que me sorprendió: casi nunca se activa, se hereda.

Fui a mi propio Caddyfile a buscar la línea donde configuré esto para poder explicarla. No existe. En 373 líneas de configuración no hay una sola directiva de curvas ni de algoritmos de intercambio. Mi servidor corre la imagen oficial caddy:2-alpine, versión 2.11.3, y negocia X25519MLKEM768 porque el binario viene compilado con un Go que lo trae encendido por defecto. En el artículo anterior recompilé ese mismo Caddy con Go 1.27, pero eso fue una prueba de laboratorio para los certificados: en producción corre la imagen oficial, sin tocar.

Yo estoy en la misma situación que los 136 sitios que lo recibieron de su borde. La única diferencia es quién me lo regaló: a ellos su proveedor, a mí el equipo de Caddy.

Estas son las versiones desde las que viene por defecto:

Ninguna de esas filas pide configuración: piden una actualización.

Eso reencuadra el 7 % de los sitios con infraestructura propia. Lo más probable no es que hayan decidido no usarla: es que corren software anterior a esas versiones. Los 110 que negocian X25519 tienen TLS 1.3 moderno y les falta solo un salto de versión de su librería. Los 48 con curvas NIST antiguas tienen algo más de camino.

Para comprobarlo tú mismo

En tu propio servidor, con OpenSSL 3.5 o superior:

openssl s_client -groups X25519MLKEM768 -connect tudominio.cl:443 \
  -servername tudominio.cl </dev/null 2>/dev/null | grep "Negotiated TLS1.3 group"

Si responde X25519MLKEM768, ya lo tienes. Si no responde nada, tu servidor todavía no sabe hablarlo.

Y una advertencia que me costó tiempo en el artículo anterior: verifica con el binario que usa tu programa, no con el del terminal. En el mismo Mac conviven el OpenSSL 3.6.3 de la línea de comandos y el 3.0.16 que trae Python, y responden cosas distintas a la misma pregunta.

Qué haría hoy

La tarea concreta cabe en una tarde: correr el comando de arriba contra tus propios dominios, y para los que no respondan, mirar qué versión de OpenSSL o de Go tiene el binario que los sirve. En la mayoría de los casos el arreglo es una actualización que ya tenías pendiente por otras razones.

Lo que más me quedó dando vueltas de esta medición no es el 47 %. Es que la Superintendencia de Pensiones y el Registro Civil corren sobre la misma red, con el mismo proveedor, y uno lo tiene y el otro no. No hubo una decisión de política ni un presupuesto de por medio. La diferencia está en el software que atiende la conexión.

La lista completa

Publicar solo el porcentaje obliga a creerme. Aquí están los 304 dominios uno por uno, con el grupo que negoció cada uno y quién le sirve el TLS, para que cualquiera tome el suyo, corra el comando de arriba y me contradiga si me equivoqué.

Fuentes

Las normas.

• FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard. ML-KEM, la mitad post-cuántica de X25519MLKEM768.
• NIST IR 8547: Transition to Post-Quantum Cryptography Standards. Los plazos de 2030 y 2035.
• draft-kwiatkowski-tls-ecdhe-mlkem-03. El borrador que define el grupo X25519MLKEM768 que se midió aquí.

Lo que originó la medición.

• Cloudflare: Automatic Key Exchange, 8 de septiembre de 2026. Cómo sondean los orígenes cada 24 horas para elegir el acuerdo de clave más seguro que cada uno acepte.
• Cloudflare: soporte de criptografía post-cuántica por producto. De ahí salen las versiones mínimas de la tabla.

La muestra.

• Lista Tranco. El ranking del que salieron los 320 dominios .cl.