# Huellas TLS JA4 y Private Access Tokens en Verify

> El borde calcula ahora la huella JA4 de cada conexión TLS; tls_mismatch comprueba con ella la pila TLS de cada navegador. Los Private Access Tokens están listos como señal que baja la puntuación, aún sin activar.

El borde calcula ahora la huella [JA4](https://github.com/FoxIO-LLC/ja4) de cada conexión TLS que termina, a partir del ClientHello, y descarta los bytes originales. Los eventos de seguridad y los de agentes IA la guardan en `tls_fingerprint` (antes era un hash interno de 16 caracteres), y la [trampa](https://developers.openwaf.dev/es/ai-crawl-control/trap-and-tarpit/#marks) marca a los clientes por ella. Queda vacía cuando otro proxy terminó TLS delante del borde, o en HTTP sin cifrar.

La [señal de riesgo](https://developers.openwaf.dev/es/waf/verify-risk/#signals) `tls_mismatch` comprueba ahora que un Chromium, Firefox o Safari reciente viene de la pila TLS de ese navegador, por rasgos estables y no por huellas exactas: BoringSSL en Chromium, NSS en Firefox y la pila de red de Apple en Safari y en cualquier navegador de iOS. Un Chromium automatizado cuyo User-Agent dice ser Safari o Firefox ya la hace saltar. Ver [Pilas TLS](https://developers.openwaf.dev/es/waf/verify-risk/#tls).

Una señal nueva, `pat_valid` (−20), baja la puntuación de un reto cuando el dispositivo presenta un [Private Access Token](https://developers.openwaf.dev/es/waf/verify-risk/#pat) válido. Aún no está activada: no hay ningún emisor de tokens configurado, porque los emisores que aceptan los dispositivos de Apple necesitan antes un acuerdo con OpenWAF. Hasta entonces nada cambia para los visitantes.