Test de huella TLS

Una huella TLS es una firma derivada del ClientHello de su navegador: las suites de cifrado, las extensiones, las curvas elípticas y las versiones de TLS que anuncia durante el handshake, en su orden exacto. Como cada navegador, sistema operativo y biblioteca HTTP monta esos parámetros de forma distinta, la huella identifica de forma fiable qué tipo de cliente se está conectando. Los sistemas antibot la usan para distinguir navegadores reales de automatización antes de leer un solo byte de su petición.

JA3 es el método original: concatena la versión de TLS, las suites de cifrado, las extensiones y las curvas del ClientHello y las convierte en un MD5 de 32 caracteres. JA4 es su sucesor moderno: es legible para humanos, incluye más campos (como ALPN y el número de extensiones) y resiste mejor la aleatorización que introducen los navegadores recientes. JA4 es más difícil de evadir y se está imponiendo como estándar en Cloudflare y en otros proveedores, así que a menudo verá ambos indicados uno junto al otro.

JA3N es una variante normalizada de JA3. Los navegadores modernos como Chrome barajan el orden de las extensiones TLS en cada conexión (una función llamada GREASE o aleatorización de extensiones), lo que hace que el hash JA3 en bruto cambie de una petición a otra. JA3N ordena las extensiones en una secuencia canónica antes de calcular el hash y produce así una huella estable que no cambia en cada handshake. Esa estabilidad es justo el motivo por el que los sistemas de fingerprinting prefieren los hashes normalizados.

Si su JA3 en bruto cambia entre una comprobación y otra, casi siempre se debe a la aleatorización de extensiones. Los navegadores basados en Chromium reordenan deliberadamente las extensiones TLS e inyectan valores GREASE para que ningún hash estático le identifique. Las formas normalizadas —JA3N y JA4— eliminan ese ruido y se mantienen constantes, y por eso los proveedores antibot se apoyan en ellas y no en el JA3 en bruto.

Sí, pero es mucho más difícil que cambiar un User-Agent. Como la huella procede de la propia biblioteca TLS, no puede modificarla desde JavaScript ni desde una opción del navegador: necesita un cliente que imite el handshake de un navegador real byte a byte, como una biblioteca de suplantación TLS (curl-impersonate, utls) o un navegador antidetección construido sobre un motor Chromium auténtico. Editar cabeceras sin más no sirve de nada: el handshake ocurre antes de que se envíe ninguna cabecera.

Significa que sus dos capas cuentan historias distintas. Su cabecera User-Agent puede afirmar «Chrome 124 en Windows», pero si su handshake TLS coincide con la biblioteca requests de Python o con el cliente http de Go, el servidor ve una contradicción que ningún navegador real produciría jamás. Los sistemas antibot tratan ese desajuste como una de las señales de automatización más potentes que existen, mucho más fiable que el User-Agent por sí solo, que cualquiera puede reescribir en una línea.

Normalmente no. Una VPN o un proxy HTTP/SOCKS estándar reenvían su tráfico, pero no tocan el handshake TLS que genera su navegador, así que su JA3/JA4 no varía: solo cambia su IP. La excepción son los proxies que terminan el TLS y restablecen la conexión por su cuenta; ahí entra en juego la huella del propio proxy, lo que puede ser bueno (un handshake limpio, parecido al de un navegador) o malo (una firma de proxy evidente), según el proveedor.

Su huella procede de su cliente, así que la solución real es combinar una pila TLS coherente y fiel a la de un navegador con una IP que respalde esa historia. Los proxies residenciales y móviles de ProxyWing le dan IP limpias y de confianza que corresponden a conexiones de consumidores reales, de modo que un handshake de navegador auténtico sobre una IP residencial se lee como un usuario corriente y no como automatización de centro de datos. Junto a un navegador antidetección que genere un ClientHello auténtico, así consigue que su TLS, su IP y su User-Agent cuenten una única historia coherente.