TLS-Fingerprinting erkennt anhand von Merkmalen des Verbindungsaufbaus Muster, die mit bestimmter Clientsoftware zusammenhängen. Bei der Registrierung helfen diese Muster zu prüfen, ob die Browserangabe zur Verbindung passt. Sie stellen weder die Identität des Besuchers fest noch, ob sich diese Person schon einmal registriert hat.
Die TLS-Befunde von Emvero halten Abweichungen von Browserangaben fest. Beide sind informativ: Sie haben default_raises: false und verlangen für sich allein weder eine E-Mail-Bestätigung noch die Ablehnung der Registrierung. Für die Einordnung ist entscheidend, was verglichen wurde.
Was der TLS-Verbindungsaufbau zeigt
Beim Aufbau einer TLS-Verbindung sendet der Client ein ClientHello mit den angebotenen Fähigkeiten. Dazu gehören Cipher Suites und Erweiterungen wie unterstützte Protokollversionen und Gruppen für den Schlüsselaustausch. Der Server nutzt diese Angaben bei der Aushandlung. Die ClientHello-Definition in RFC 8446 beschreibt den Aufbau.
Ein Fingerprinting-Verfahren wählt Merkmale aus und fasst sie zusammen, um Verbindungen mit ähnlichem Softwareverhalten zu vergleichen. JA3 und JA4 sind solche Verfahren. Dasselbe Muster kann viele Installationen einer Software beschreiben. Es ist keine einer Person zugewiesene Kennung.
Der Chromium-Vorschlag zur zufälligen Reihenfolge der Erweiterungen soll verhindern, dass Systeme von einem unveränderlichen Handshake abhängen. Ein Fingerprint, der die Reihenfolge bewahrt, kann sich anders verhalten als einer, der sie normalisiert. Ein Muster ist daher eine Beobachtung nach bestimmten Regeln.
TLS-Belege und Browser- oder Geräte-Fingerprinting
TLS-Belege stammen aus der Verbindung. Browser-Fingerprinting kann weitere Merkmale verbinden, darunter Werte, die Code im Browser misst. Der W3C-Leitfaden zu Fingerprinting unterscheidet passive Beobachtungen von aktiven Verfahren wie dem Rendern grafischer Muster. Canvas-Ausgaben sind ein solcher Eingangswert. Audioverarbeitung liefert andere Werte; der Web-Audio-Arbeitsentwurf behandelt deren Datenschutzaspekte.
Solche Daten können in umfassendere Versuche eingehen, Geräte oder Sitzungen miteinander zu verknüpfen. Ein TLS-Konsistenzbefund hat eine engere Bedeutung. Die Signup-Antwort von Emvero liefert weder eine dauerhafte Visitor ID noch den ursprünglichen Fingerprint als Kontokennung. Ein öffentlicher JA3/JA4-Lookup oder Browser-Fingerprint-Test wird ebenfalls nicht angeboten.
Ein Proxy, der TLS terminiert, baut eine eigene Verbindung mit einem eigenen ClientHello zum Ziel auf. Das beschreibt RFC 8446 zu TLS-Terminierung. Dass Daten durch einen Tunnel laufen, belegt keine TLS-Terminierung. Nicht jedes VPN ersetzt den Handshake des Browsers.
Was Emvero mit der Browserangabe vergleicht
Die Erfassung beobachtet die Verbindung, über die die Seite einen Besuchstoken anfordert. Die TLS-Vergleiche verwenden die User-Agent-Angabe aus dem ersten Request dieser Verbindung. Ihr Backend sendet den Token später mit der Signup-Prüfung. Seine API-Verbindung zu Emvero ist von der beobachteten Besuchsverbindung getrennt.
Der Erfassungsdienst vergleicht die Angabe mit Kennzeichnungen des beobachteten Handshake-Musters. Sie stammen aus den Verbindungen, die dieses Muster aufweisen, und deren Softwareangaben. Es handelt sich um einen Zusammenhang im beobachteten Datenverkehr, nicht um eine vertrauenswürdige Aussage über die installierte Software.
Auch User-Agent und Client Hints können einander widersprechen. Das ist ein eigener Vergleich von HTTP-Angaben. Er macht keine der Angaben zum Beweis für die Browser-Engine und ist von den folgenden TLS-Vergleichen zu unterscheiden.
Abweichende Engine: fp_client_tls_mismatch
Die von der User-Agent-Angabe nahegelegte Engine gehört hier nicht zu den Engines, die mit dem TLS-Muster verbunden sind. Der Vergleich betrifft eine Engine-Angabe und Kennzeichnungen des beobachteten Bestands; er bestimmt keine genaue Browsermarke. Der Befund gehört zur Klasse identity und hat default_raises: false.
Eine Anwendung kann ihren eigenen Netzwerkstack nutzen und einen browserähnlichen User-Agent senden. Das kann dieselbe Abweichung erzeugen wie eine absichtlich irreführende Angabe. Der Befund allein unterscheidet diese Ursachen nicht.
Abweichende Chromium-Version: fp_client_tls_version_mismatch
Dieser Befund vergleicht die angegebene Chromium-Hauptversion mit dem Versionsbereich des TLS-Musters. „Version“ bezeichnet hier Chromium, keinen Widerspruch zwischen TLS 1.2 und TLS 1.3. Der Bereich ist eine aus beobachtetem Verkehr abgeleitete Versionsepoche. Er bestimmt nicht die genaue installierte Browserversion.
Der gekürzte Befund verwendet fiktive Beispielwerte. Die Zahlen veranschaulichen den Vergleich und sind keine Zuordnungstabelle aktueller Chromium-Versionen:
{
"code": "fp_client_tls_version_mismatch",
"class": "identity",
"default_raises": false,
"detail": {
"direction": "claim_newer",
"epoch": "131-150",
"claimed_version": 153
}
}
claim_newer bedeutet, dass die Angabe neuer als die zugeordnete Epoche ist. Es bedeutet nicht, dass der Dienst Chromium 150 auf dem Gerät gemessen hat. Eine Anwendung, die eine aktuelle Chrome-Version angibt, aber ein älteres System-WebView nutzt, kann diese Abweichung verursachen. Auch der Versionsbefund bleibt deshalb informativ.
Prüfen, ob der Vergleich ausgeführt wurde
Ein fehlender Abweichungsbefund kann Übereinstimmung bedeuten. Es kann aber auch sein, dass kein Vergleich möglich war. Prüfen Sie not_evaluated und den verfügbaren Vergleichsstatus, bevor Sie eine fehlende Meldung als Übereinstimmung werten.
fp_client_tls_not_evaluated kennzeichnet einen nicht abgeschlossenen Engine-Vergleich. fp_client_tls_version_not_evaluated gilt entsprechend für die Chromium-Version. Gründe können ein unbeschriftetes Handshake-Muster, fehlende Kennzeichnungen oder ein User-Agent ohne verwertbare Angabe sein. Der jeweilige Status steht in signals.client_claims.tls oder signals.client_claims.tls_version, sofern diese Objekte vorhanden sind.
claimed_engine und labeled_engine werden als not_carried zurückgegeben, weil der Token die zugrunde liegenden Engine-Werte nicht mitführt. Das begrenzt die ausgegebenen Details und ist von der Frage zu trennen, ob der Vergleich lief. Der Signalstatus unavailable betrifft die gesamte Auswertung und belegt keinen sicheren Besuch.
TLS-Befunde in die Registrierungsentscheidung einordnen
Diese TLS-Codes gehen nach der Standardrichtlinie nicht als erhöhende Befunde in signal_codes ein. Andere Belege können weiterhin eine Bestätigung verlangen, und das E-Mail-Ergebnis kann eine Ablehnung begründen. Lesen Sie die zurückgegebene äußere action; leiten Sie sie nicht aus einem einzelnen TLS-Befund ab. Der Artikel zu Signup-Ergebnissen erklärt das Zusammenspiel von Befunden und Empfehlung.
Bestätigung und Kontoberechtigungen liegen bei Ihrer Anwendung. Nutzen Sie Signup Protection, wenn Sie dafür E-Mail- und Besuchsbelege benötigen. Der Installationsleitfaden zum Schutz der Registrierung beschreibt Formular, Token, Serveranfrage und Aktion.