La identificación por huellas TLS usa características del establecimiento de una conexión para reconocer patrones asociados a programas cliente. Durante el registro, esos patrones ayudan a comprobar si lo que declara el navegador concuerda con la conexión. No identifican al visitante ni establecen si esa persona ya se había registrado.
Los hallazgos TLS de Emvero registran diferencias con las declaraciones del navegador. Ambos son informativos: tienen default_raises: false y por sí solos no exigen confirmar el correo ni rechazan el registro. Entender qué se comparó permite decidir qué peso dar al hallazgo.
Qué revela el establecimiento de TLS
Al iniciar una conexión TLS, el cliente envía un ClientHello con las capacidades que ofrece. Incluye conjuntos de cifrado y extensiones como las versiones de protocolo y los grupos de intercambio de claves admitidos. El servidor usa esas propuestas para negociar la conexión. La definición de ClientHello en RFC 8446 describe su estructura.
Un método de huellas selecciona y resume características para comparar conexiones de programas con comportamientos similares. JA3 y JA4 son dos métodos. Un patrón compartido puede describir muchas instalaciones del mismo programa; no es un identificador asignado a una persona.
La propuesta de Chromium para permutar extensiones describe la aleatorización de su orden en ClientHello para evitar sistemas que dependan de una negociación invariable. Una huella que conserva el orden y otra que lo normaliza pueden comportarse de forma distinta. El patrón es una observación realizada bajo unas reglas concretas.
Evidencia TLS y huellas de navegador o dispositivo
La evidencia TLS procede de la conexión. Las huellas de navegador pueden combinar otras características observables, incluidos valores medidos por código en el navegador. La guía de W3C sobre huellas distingue observaciones pasivas de técnicas activas, como dibujar patrones gráficos. El resultado de Canvas es un ejemplo. El procesamiento de audio aporta otro tipo de datos, tratado en las consideraciones de privacidad del borrador de Web Audio.
Estos datos pueden formar parte de intentos más amplios de relacionar dispositivos o sesiones. Un hallazgo de coherencia TLS tiene un significado más limitado. La respuesta de registro de Emvero no proporciona un Visitor ID persistente ni una huella original para usar como identificador de cuenta. Tampoco ofrece una consulta pública de JA3/JA4 ni una prueba de huella del navegador.
Un proxy que termina TLS crea una conexión independiente y su propio ClientHello hacia el destino, como explica RFC 8446 sobre terminadores TLS. Enrutar el tráfico por un túnel no demuestra que se haya terminado TLS. No se debe asumir que todas las VPN sustituyen la negociación del navegador.
Qué compara Emvero con la declaración del navegador
La infraestructura de captura observa la conexión con la que la página pide el token de visita. Las comparaciones TLS usan el User-Agent de la primera petición de esa conexión. El backend envía después el token con la comprobación de registro; su conexión de API a Emvero es distinta de la visita observada.
El servicio compara la declaración con las etiquetas asociadas al patrón de negociación observado. Esas etiquetas proceden de las conexiones que presentan el patrón y del software que declaran usar. Describen una asociación en el tráfico observado, no una declaración fiable del programa instalado.
User-Agent y Client Hints también pueden contradecirse. Esa es otra comparación entre declaraciones HTTP. No convierte ninguna de ellas en prueba del motor del navegador y debe distinguirse de las comparaciones TLS siguientes.
Diferencia de motor: fp_client_tls_mismatch
El motor que se deduce del User-Agent no figura entre los asociados al patrón TLS de la conexión. Se compara una declaración de motor con etiquetas del conjunto observado; no se identifica una marca exacta de navegador. El hallazgo pertenece a la clase identity y tiene default_raises: false.
Una aplicación puede usar su propia pila de red y enviar un User-Agent parecido al de un navegador. Eso puede producir la misma diferencia que una declaración engañosa intencionada. El hallazgo por sí solo no distingue las causas.
Diferencia de versión de Chromium: fp_client_tls_version_mismatch
Este hallazgo compara la versión principal declarada de Chromium con el intervalo de versiones asociado al patrón TLS. Aquí «versión» se refiere a Chromium, no a una diferencia entre TLS 1.2 y TLS 1.3. El intervalo es una época de versiones inferida del tráfico observado; no identifica la versión exacta instalada.
El hallazgo abreviado usa valores ficticios. Los números ilustran la comparación y no son un mapa de referencia de las versiones actuales de Chromium:
{
"code": "fp_client_tls_version_mismatch",
"class": "identity",
"default_raises": false,
"detail": {
"direction": "claim_newer",
"epoch": "131-150",
"claimed_version": 153
}
}
claim_newer significa que la declaración es más reciente que la época asociada. No significa que el servicio haya medido Chromium 150 en el dispositivo. Una aplicación que declare una versión reciente de Chrome mientras usa un WebView antiguo del sistema puede producir esa diferencia. Por eso el hallazgo de versión también es informativo.
Compruebe si se realizó la comparación
La ausencia de un hallazgo puede significar coincidencia, pero también que no fue posible comparar. Inspeccione not_evaluated y el estado disponible antes de interpretar la ausencia como concordancia.
fp_client_tls_not_evaluated identifica una comparación de motor que no pudo completarse. fp_client_tls_version_not_evaluated hace lo mismo para la versión de Chromium. Entre las causas están un patrón sin etiquetas, etiquetas no disponibles o un User-Agent sin una declaración utilizable. El estado correspondiente se comunica en signals.client_claims.tls o signals.client_claims.tls_version, cuando existen esos objetos.
claimed_engine y labeled_engine se devuelven como not_carried porque el token no contiene los valores de motor subyacentes. Esto limita el detalle comunicado y es distinto de si se realizó la comparación. El estado de señales unavailable afecta a la evaluación completa y no establece que la visita sea segura.
Use los hallazgos TLS dentro de la decisión de registro
Estos códigos TLS no entran en signal_codes como hallazgos que eleven la acción según la política por defecto. Otra evidencia puede seguir exigiendo confirmación y el correo puede determinar un rechazo. Lea la action externa recibida; no la deduzca de un hallazgo TLS aislado. El artículo sobre resultados de registro explica cómo encajan los hallazgos y la recomendación combinada.
Su aplicación controla la confirmación y los permisos de cuenta. Use Signup Protection cuando necesite evidencia del correo y de la visita para esa decisión. La guía de instalación para proteger el registro describe la secuencia de formulario, token, petición del servidor y acción.