TLS post-cuántico en 2026: por qué el JA4 coincidente ya no salva al scraper

Hace un año, el esquema era claro: tomas un cliente que puede falsificar el apretón de manos TLS, seleccionas un perfil para el Chrome más reciente, obtienes un JA4 coincidente y el anti-bot te deja pasar. En 2026, esta receta comenzó a fallar por una razón que no tiene nada que ver con "eludir protecciones". Los navegadores han cambiado masivamente a un intercambio de claves post-cuántico, mientras que la mayoría de los stacks de scraping no lo han hecho. Y ahora, la falta de un intercambio de claves post-cuántico es en sí misma una señal de automatización.

Analicemos por criterios: qué exactamente ha cambiado en el apretón de manos, qué stacks ya han migrado, cuáles no, y por qué un hash JA4 coincidente ha dejado de ser una condición suficiente.

Qué ocurrió: el intercambio post-cuántico se convirtió en norma, no en exótica

El intercambio híbrido de claves post-cuánticas es una combinación de la curva elíptica clásica X25519 y el mecanismo de rejilla ML-KEM (estándar NIST FIPS 203). La sesión permanece protegida si al menos uno de los dos componentes es resistente. El sentido es protegerse contra el escenario de "interceptar ahora, descifrar después", cuando el tráfico se archiva con la esperanza de un futuro ordenador cuántico.

La cronología de implementación en los clientes:

• Chrome 124 (abril de 2024) — el intercambio híbrido post-cuántico está habilitado por defecto; en los parches curl-impersonate esto se registra como "curvas X25519Kyber768/X25519MLKEM, introducidas en Chrome 124 y 130".
• Firefox 132 (noviembre de 2024) — soporte habilitado.
• Safari en iOS y macOS — el intercambio post-cuántico llegó en octubre de 2025.
• OpenSSL 3.5.0 (abril de 2025) — los grupos híbridos X25519MLKEM768, SecP256r1MLKEM768 y SecP384r1MLKEM1024 se incluyeron en la lista predeterminada de grupos TLS.
• Go 1.24 (febrero de 2025) — X25519MLKEM768 se incluye en crypto/tls por defecto, a menos que Config.CurvePreferences se especifique explícitamente.

Desde la perspectiva de la infraestructura, la imagen es aún más clara. Cloudflare Radar en abril de 2026 mostraba alrededor del 67% del tráfico HTTPS humano con cifrado post-cuántico — frente al 32% en enero de 2025. Akamai hizo del intercambio de claves post-cuánticas el estándar para todas las conexiones de clientes el 31 de enero de 2026, completando el despliegue en marzo. Según mediciones de la industria, alrededor del 57,4% de todas las transacciones en navegadores ya están listas para post-cuántico, con Chrome teniendo una proporción de capacidad para PQ de alrededor del 93%.

Presta atención a la asimetría: el soporte del lado de los servidores de origen crece mucho más lentamente (en Cloudflare, alrededor del 9%). Es decir, el post-cuántico hoy en día es, ante todo, una característica del cliente. Justo lo que le interesa al anti-bot.

Criterio 1: tamaño del intercambio de claves y estructura ClientHello

El intercambio de claves post-cuántico no es "solo otro indicador en la extensión". Es físicamente grande: alrededor de 1124 bytes frente a 36 bytes del clásico X25519. Las consecuencias son evidentes a simple vista a nivel de paquetes.

ClientHello con intercambio de claves post-cuántico supera los 1400 bytes y deja de caber en un solo segmento TCP. Se divide en dos o más paquetes. Y luego comienza lo más interesante para la detección: el patrón de fragmentación varía entre diferentes implementaciones. Cómo exactamente el stack corta un gran ClientHello, en qué orden envía los segmentos, con qué temporización — este es un comportamiento observable que no se deriva del hash JA4 y que casi nadie de los autores de herramientas de scraping reproduce conscientemente.

Conclusión práctica: el anti-bot ha adquirido una capa que opera por debajo de la huella digital habitual. Puedes recopilar perfectamente una lista de cifrados y extensiones, pero te delatarás por cómo tu stack coloca los bytes en el socket.

Criterio 2: consistencia con la versión del navegador declarada

La principal trampa del año 2026 es la desincronización entre quién te presentas y lo que realmente hace tu stack TLS.

Las plataformas anti-bot mantienen bases de datos de ClientHello de referencia. Una solicitud que en User-Agent y en JA4 declara Chrome 131, pero llega sin el intercambio de claves post-cuántico, no coincide con ningún Chrome 131 válido conocido. No es "sospechoso" — es una combinación lógicamente imposible. Un verdadero Chrome de esa versión no puede enviar un intercambio de claves clásico con la configuración predeterminada.

Qué tan bien se separa esto mediante aprendizaje automático también ha sido calculado. El clasificador CatBoost en características JA4 en estudios muestra AUC 0.998 y precisión 0.9863; el tráfico post-cuántico se diferencia del clásico con una precisión de alrededor del 98%. No es "heurística con falsos positivos", es una característica prácticamente determinista.

Criterio 3: preparación de stacks específicos

Aquí es donde se traza la verdadera línea de separación. Desglosemos por grupos.

Envía intercambio de claves PQ por defecto

• Chrome 124+, Firefox 132+, Safari (iOS/macOS desde octubre de 2025) — el estándar con el que te comparan.
• Go 1.24+ — crypto/tls incluye X25519MLKEM768 automáticamente, a menos que hayas sobrescrito CurvePreferences. Un matiz importante: hay post-cuántico, pero el JA4 de un cliente Go desnudo sigue sin ser de navegador. Obtienes una huella "compatible con PQ, pero no parecida a Chrome".
• Node.js 24 — incluye su propio OpenSSL 3.5, así que la lista predeterminada de grupos ya incluye híbridos. Además, en node:crypto se han añadido ML-KEM a través de crypto.encapsulate()/decapsulate() y ML-DSA en sign()/verify().

Dependen de lo que estén vinculados

• Python: requests, aiohttp, httpx — utilizan el módulo ssl, que toma OpenSSL del sistema. En Ubuntu 24.04, el sistema tiene OpenSSL 3.0.x, donde no hay grupos post-cuánticos en absoluto. Para obtener PQ, necesitas compilar OpenSSL 3.5 desde el código fuente, colocarlo a través de LD_LIBRARY_PATH y, probablemente, recompilar Python. En la práctica, esto significa: un scraper típico de Python en 2026 envía un intercambio de claves clásico y se ve como una anomalía en Akamai.

Pueden, pero solo si seleccionas el perfil correcto

• curl_cffi / curl-impersonate — el soporte para curvas post-cuánticas en el fork está presente y declarado explícitamente. Pero la lista de objetivos va desde chrome99 hasta chrome146 (en el fork — hasta chrome150), y los perfiles antiguos reproducen el apretón de manos de su época, es decir, sin PQ. Copiar y pegar impersonate="chrome116" de una guía de hace dos años es un camino directo a la detección.
• uTLS — el mismo principio: los perfiles HelloChrome por debajo del 131 no contienen intercambio de claves PQ. Además, en la biblioteca de 2026 se cerraron dos vulnerabilidades de huella: CVE-2026-26995 (versiones 1.6.0–1.8.1) y CVE-2026-27017 (1.6.0–1.8.0, desincronización en la selección de cifrado para GREASE ECH — Chrome lo elige de manera determinista, mientras que parrot en uTLS lanzaba una moneda entre AES y ChaCha20, lo que es imposible para un verdadero Chrome). Necesitas actualizar al menos a 1.8.2.

El denominador común: las herramientas en su mayoría han alcanzado el nivel. El problema no está en ellas, sino en que las configuraciones envejecen más rápido que los navegadores. Un perfil que era ideal en 2024 hoy actúa como un marcador.

Cómo verificar tu stack en cinco minutos

1. Envía una solicitud con tu cliente de producción a https://tls.peet.ws/api/all o ja4db.com — devuelven JA3/JA4 en vivo y el desglose de ClientHello en JSON.
2. Busca en el desglose la lista de supported_groups y key_share. Busca X25519MLKEM768 (o X25519Kyber768 en perfiles antiguos). Si solo hay x25519/secp256r1 — no hay intercambio post-cuántico.
3. Compara esto con la versión del navegador que estás declarando. Declara Chrome 131+ y no ves grupos PQ — la combinación no es válida, corrige el perfil.
4. Mira el tamaño de ClientHello. Menos de ~1400 bytes con un Chrome reciente declarado — es el mismo indicio, solo desde otro ángulo.
5. Ejecuta la verificación desde cada nodo de salida, no solo desde la máquina de trabajo: la inspección SSL en la puerta de enlace corporativa o en el proveedor puede reescribir el apretón de manos por ti.

Qué hacen aquí los proxies

Es importante no mezclar dos capas independientes. El intercambio de claves post-cuántico se refiere al apretón de manos, la reputación de la dirección se refiere a la red. El anti-bot los considera por separado y los suma.

De aquí se derivan dos consecuencias prácticas. Primero: una IP residencial ideal no salvará una solicitud que a nivel TLS se presenta como Chrome 131 sin un grupo PQ — perderás incluso antes de que el servidor mire la dirección. Segundo, el espejo: un apretón de manos post-cuántico bien formado no ayudará si un centenar de tus sesiones provienen de una subred de centro de datos con mala reputación. Ambos niveles deben ser reparados, y se reparan con diferentes herramientas.

Desglose práctico por tareas: para objetivos detrás de Akamai y Cloudflare, donde se consideran tanto el apretón de manos como la red, es razonable optar por proxies residenciales y al mismo tiempo elevar el objetivo de impersonate a un Chrome reciente. Para aplicaciones móviles y plataformas donde el peso de la reputación IP es mayor que los requisitos de TLS, a menudo ganan proxies móviles. Y para APIs propias, descargas de socios y monitoreo interno, donde no hay anti-bot, no tiene sentido pagar de más por residenciales — con centros de datos es suficiente.

Si estás comenzando a lidiar con la huella desde cero, comienza con la base: cómo funciona JA4 y qué incluye. Y cuando se trata no de un cliente HTTP, sino de un navegador completo, la comparación de construcciones stealth y sus debilidades se ha recopilado por separado — nodriver, Camoufox y Patchright en mediciones de 2026.

Conclusión

El intercambio de claves post-cuántico no fue concebido como un mecanismo anti-bot. Se convirtió en uno incidentalmente: los navegadores migraron a él rápida y masivamente, la infraestructura (Akamai — desde el 31 de enero de 2026) lo hizo el estándar, y los stacks de scraping se dividieron en tres grupos — aquellos que ya han migrado, aquellos que dependen de OpenSSL del sistema y aquellos que solo pueden hacerlo con un perfil reciente.

La verificación se reduce a una pregunta: ¿envía tu cliente X25519MLKEM768 y se alinea con la versión del navegador que declaras? Si no — un JA4 coincidente no te salvará, porque ya no se compara solo el hash, sino toda la forma del apretón de manos en su totalidad: tamaño del intercambio de claves, número de segmentos TCP y orden de envío. La buena noticia es que esto se soluciona en la mayoría de los casos actualizando el perfil y la versión de la biblioteca, y no reescribiendo el scraper.