Fingerprinting TLS explicado

Qué es el fingerprinting TLS

El fingerprinting TLS identifica el software detrás de una conexión HTTPS inspeccionando el primer mensaje del handshake. Cuando un cliente abre una conexión TLS, envía un paquete Client Hello que revela la versión TLS, las cipher suites, las extensiones y su orden. Esa combinación es una firma a nivel de bytes de la biblioteca TLS subyacente.

El punto clave: el Client Hello es un detalle de implementación, no un header que el scraper elija. Puedes poner cualquier cosa en el User-Agent, pero no puedes cambiar fácilmente la lista de ciphers de tu biblioteca TLS. Un script de Python que dice ser Chrome queda expuesto en el handshake.

Por qué el fingerprinting TLS importa ahora

El tráfico automatizado ya es mayoría en la web. El Bad Bot Report 2025 de Imperva sitúa el tráfico automatizado en el 51 % del tráfico web total de 2024, mayoría por primera vez en una década, con un 37 % de bots maliciosos (Imperva, 2025). Un sitio que no puede distinguir una biblioteca de un navegador está ciego frente a más de un tercio de su propio tráfico, y esa ceguera resulta más cara precisamente donde apuntan los scrapers: endpoints de login, páginas de precios, APIs de búsqueda y feeds RSS.

El desplazamiento de tráfico humano a tráfico agéntico empuja la pregunta hacia la capa de protocolo. Los headers mienten, las IPs rotan, el user-agent es un campo de texto libre. El handshake TLS es lo único que el scraper tiene que producir antes de que se transmita ningún body HTTP, y el código que lo produce es el código que realmente corre.

Tipos de fingerprints TLS (JA3, JA4, JA4H)

Tres formatos de fingerprint dominan el panorama en 2026.

**JA3.** El primer método de fingerprinting TLS de adopción amplia, publicado por ingenieros de Salesforce en enero de 2019. JA3 toma cinco campos del Client Hello (versión, ciphers aceptadas, lista de extensiones, curvas elípticas y formatos de punto), los concatena y hashea el resultado con MD5 en un fingerprint de 32 caracteres.

El método funcionó durante años. A principios de 2023, Chrome empezó a aleatorizar el orden de las extensiones TLS en su Client Hello. Las matemáticas son brutales: un solo cliente Chrome enviando 16 extensiones en orden aleatorio puede producir 16 factorial ordenaciones distintas, aproximadamente 20,9 billones de hashes JA3 distintos del mismo navegador en la misma máquina. Como lo formuló Stamus Networks, JA3 quedó inútil para identificar clientes y user-agents. Firefox siguió con una aleatorización similar.

JA4 y la suite JA4+

**JA4.** FoxIO publicó JA4 en septiembre de 2023 para corregir el problema de aleatorización de forma directa. La solución es simple: ordenar las ciphers y extensiones alfabéticamente antes del hashing. El orden aleatorio ya no cambia la salida porque la salida no dependía del orden. JA4 también reestructuró el fingerprint en formato `a_b_c` con tres segmentos que pueden consultarse por separado.

**JA4+.** JA4 es un miembro de una suite más amplia. JA4+ incluye JA4S para servidores TLS, JA4H para patrones de petición HTTP, JA4X para generación de certificados X.509, JA4T para la huella del stack TCP y JA4SSH para conexiones SSH. Cada uno captura una capa distinta de la conexión, y los segmentos están diseñados para ser composables. A principios de 2025, JA4 ya había llegado a Cloudflare y Fastly en sus productos de bot management.

Una advertencia del spec de FoxIO: el JA4 de un navegador se desplaza aproximadamente una vez al año cuando su biblioteca TLS se actualiza. Las bases de datos de fingerprints tienen que mantener esas actualizaciones o acumulan falsos positivos contra el último Chrome.

Cómo funciona el fingerprinting TLS

Cada navegador, cada biblioteca de scraping y cada framework de bots presenta una combinación distinta de ciphers y extensiones. La biblioteca requests de Python tiene un hash JA3, curl otro, Firefox el suyo propio. Un scraper que envía `Mozilla/5.0...` en el User-Agent pero produce el JA3 de Python en el cable ya se ha delatado.

El cotejo sucede antes de que se intercambien datos HTTP. El cliente abre la conexión TCP, envía el Client Hello como primer mensaje TLS, el edge captura el patrón de bytes, lo hashea o lo ordena según las reglas JA3 o JA4, y busca el hash contra una base de datos de firmas. Si el fingerprint no coincide con el user-agent declarado, el edge tiene una decisión que tomar antes de que arranque la petición HTTP.

Cómo identificar bots por fingerprints TLS

La escala a la que opera el fingerprinting TLS se entiende mejor con cifras. Cloudflare analiza, según sus propios datos, más de 15 millones de fingerprints JA4 únicos al día a partir de más de 500 millones de user-agents y miles de millones de IPs (Cloudflare, 2024). Ese es el conjunto agregado de señales que maneja a diario un proveedor edge grande.

La parte útil de ese conjunto es lo que dice sobre lo que no es un navegador. Las bibliotecas HTTP estándar como requests de Python, `net/http` de Go o axios de Node producen handshakes TLS que ningún navegador real enviaría. El orden de ciphers es distinto. El conjunto de extensiones es distinto. Faltan los valores GREASE (los bytes intencionadamente inválidos que Chrome inyecta para disciplinar middleboxes). El comportamiento con los session tickets es distinto. No hace falta machine learning para cazarlas. Un lookup contra un puñado de fingerprints de bibliotecas conocidas basta para marcar el primer paquete.

Dos checks concretos afloran la mayor parte del tráfico de bibliotecas en la práctica. Cotejar el orden de ciphers del Client Hello contra el orden publicado para el navegador declarado en el user-agent. Cotejar la presencia de valores GREASE contra lo que esa versión de navegador emite. Una discrepancia en cualquiera de los dos puntos es una señal de que el request no es lo que dice ser.

Cómo responder cuando los bots falsifican fingerprints

Los scrapers vieron venir a JA3 hace años. Existe ya una pequeña industria de bibliotecas de impersonación construidas específicamente para reproducir handshakes reales de navegador desde scripts. curl-impersonate es un fork de curl compilado contra NSS y BoringSSL que produce Client Hellos byte a byte idénticos a los de versiones recientes de Chrome, Firefox, Edge y Safari. uTLS es un fork de `crypto/tls` en Go que expone la construcción del ClientHello. CycleTLS trae la misma capacidad a Node.js. curl_cffi da a Python el handshake de curl-impersonate como reemplazo directo de la biblioteca `requests`. Las cuatro son open source. Las cuatro se instalan en trivialidades.

Un estudio de UC Davis de 2025 probó veinte servicios comerciales de bots contra dos sistemas de detección líderes y midió tasas medias de evasión del 52,93 % contra DataDome y del 44,56 % contra BotD a lo largo de más de medio millón de peticiones (Venugopalan et al., IMC 2025). Llamémoslo por su nombre: datos revisados por pares mostrando que más de la mitad del tráfico de scraping comercial atraviesa uno de los sistemas de detección más desplegados del sector.

La respuesta es por capas, no lateral. Los propios ingenieros de Cloudflare lo escriben claro en el post que anuncia JA4 Signals: los fingerprints se falsifican con facilidad, cambian con frecuencia y los patrones de tráfico y comportamiento evolucionan constantemente. La respuesta que emparejan con JA4 es conductual: features entre peticiones calculadas sobre la última hora de tráfico global, buscando clusters que ningún navegador honesto formaría.

Un solo hash JA4 dice qué software hizo la conexión. No dice qué está haciendo ese software. Un fingerprint de Chrome falsificado llegando desde miles de IPs residenciales, golpeando cientos de páginas por minuto por sesión y pidiendo solo HTML, sigue siendo obviamente un bot. El fingerprint acota la búsqueda. El comportamiento confirma el veredicto. Retira una capa cualquiera y la eficacia cae.

Conclusiones clave

- El fingerprinting TLS identifica el software detrás de una conexión HTTPS inspeccionando el Client Hello antes de que circulen datos HTTP. Un User-Agent es una cadena que el scraper eligió; un fingerprint TLS es una propiedad del código que de hecho corre. - Tres formatos cubren el panorama: JA3 (roto por la aleatorización de extensiones de Chrome en 2023), JA4 (ordena antes de hashear, resistente a la aleatorización) y la suite JA4+ (HTTP, TCP, SSH). - Los fingerprints por sí solos no cierran la brecha. Un estudio de UC Davis de 2025 midió tasas medias de evasión del 52,93 % contra DataDome y del 44,56 % contra BotD usando bibliotecas de impersonación como curl-impersonate y uTLS. - El stack que aguanta es por capas: fingerprint TLS más SETTINGS HTTP/2, patrones conductuales y una base de datos de firmas de crawlers. Centinel corre más de 1.600 firmas contra este modelo por capas en el edge.