El fingerprinting de TLS y los hashes JA4 explicados

Cada conexión HTTPS comienza con un handshake de TLS, y cada handshake de TLS comienza con un mensaje Client Hello. Este mensaje contiene una gran cantidad de información sobre el cliente que se conecta —suites de cifrado, extensiones, curvas soportadas, algoritmos de firma— que varía significativamente entre navegadores, versiones y sistemas operativos. El fingerprinting de TLS captura esta información y la usa como señal de identificación.

¿Qué contiene un Client Hello?

Cuando un navegador se conecta a un servidor HTTPS, envía un mensaje Client Hello que contiene: la versión de TLS que soporta, la lista de suites de cifrado que está dispuesto a usar, las extensiones de TLS que incluye (como SNI, ALPN y key share), las curvas elípticas que soporta, los algoritmos de firma que acepta y los métodos de compresión que ofrece.

Cada familia de navegadores tiene una huella distintiva. Chrome, Firefox y Safari envían diferentes ordenaciones de suites de cifrado, diferentes conjuntos de extensiones y diferentes preferencias de curvas. Incluso dentro de la misma familia de navegadores, distintas versiones pueden enviar mensajes Client Hello ligeramente diferentes a medida que se añaden o se retiran suites de cifrado.

De JA3 a JA4

JA3 fue el hash original de fingerprinting de TLS, introducido por Salesforce en 2017. Concatena la versión de TLS, las suites de cifrado, las extensiones, las curvas elípticas y los formatos de punto EC en una cadena y calcula un hash MD5. Aunque fue innovador, JA3 tiene limitaciones: produce un único hash opaco que es difícil de analizar, y cambios menores en cualquier campo producen un hash completamente distinto.

JA4, introducido por FoxIO en 2023, mejora sobre JA3 de varias maneras. Produce una huella estructurada con tres componentes: un prefijo legible por humanos (como «t13d1715h2» — TLS 1.3, 17 suites de cifrado, 15 extensiones, HTTP/2), un hash ordenado de las suites de cifrado y un hash ordenado de las extensiones. Esta estructura hace que las huellas JA4 se puedan analizar de un vistazo manteniendo la precisión necesaria para la identificación.

Por qué las huellas de TLS importan para la inteligencia de dispositivos

Las huellas de TLS son valiosas porque se recopilan antes de que se ejecute cualquier JavaScript. Un bot que suplanta su user agent, falsifica su renderizado de canvas y parchea sus propiedades de navigator sigue enviando un mensaje Client Hello genuino desde cualquiera que sea la biblioteca TLS que realmente usa. Si el Client Hello dice «la biblioteca crypto/tls de Go» pero el user agent dice «Chrome 124», sabemos que algo se está suplantando.

Esta validación cruzada es extremadamente potente para la detección de bots. La mayoría de los frameworks de automatización —Selenium, Puppeteer, Playwright— usan la pila TLS nativa del navegador, por lo que sus huellas de TLS coinciden con el navegador que controlan. Pero los clientes HTTP personalizados, los scrapers basados en Go y los scripts de Python que usan la biblioteca requests tienen todos huellas de TLS distintivas que los identifican de inmediato como clientes que no son navegadores.

Estabilidad de las huellas de TLS

Una preocupación con el fingerprinting de TLS es la estabilidad a través de las actualizaciones del navegador. Cuando Chrome añade o elimina una suite de cifrado, la huella de TLS cambia. En la práctica, esto ocurre con menos frecuencia de lo que se podría esperar. La lista de suites de cifrado de Chrome es relativamente estable: los cambios importantes ocurren una o dos veces al año, no con cada versión.

El formato estructurado de JA4 ayuda aquí. El prefijo legible por humanos permanece estable a través de los cambios de versión menores (el recuento de suites de cifrado y extensiones no cambia a menudo), así que incluso cuando el hash detallado cambia, el prefijo proporciona continuidad. En nuestro sistema de identificación multinivel, los datos de la huella de TLS se colocan en el Nivel 2: lo bastante estables para contribuir a la identificación, pero procesados mediante emparejamiento entre sesiones para manejar la variación esperada.

Recopilación del lado del servidor

A diferencia de las señales del lado del cliente que requieren la ejecución de JavaScript, las huellas de TLS se recopilan por completo del lado del servidor. Nuestros servidores edge inspeccionan el handshake TLS en bruto y extraen el Client Hello antes de que se establezca la conexión. Esto significa que el fingerprinting de TLS funciona incluso cuando JavaScript está bloqueado, cuando el navegador tiene instaladas extensiones de privacidad, o cuando el cliente no es un navegador en absoluto.

Esta naturaleza del lado del servidor también hace que las huellas de TLS sean resistentes a la suplantación. Aunque teóricamente es posible elaborar un Client Hello de TLS personalizado que imite a un navegador específico, hacerlo requiere implementar TLS a bajo nivel: mucho más esfuerzo que cambiar una cadena de user agent. La mayoría de las herramientas de suplantación no lo intentan.

Integración con la identificación de dispositivos

En nuestro motor de identificación de dispositivos, la huella de TLS sirve tanto como señal como validador. Como señal, contribuye a la huella general del dispositivo con su propio peso de identificación. Como validador, proporciona una verificación cruzada contra la identidad declarada del navegador. Si las señales de JavaScript dicen «Chrome en macOS» pero la huella de TLS dice «Firefox en Linux», la discrepancia activa una marca de manipulación en nuestro análisis de Smart Signals.