Ein Cipher ist die konkrete Rechenvorschrift, mit der Daten verschlüsselt werden. Eine Cipher Suite bündelt drei Zutaten: das Verfahren für den Schlüsselaustausch, den eigentlichen Verschlüsselungsalgorithmus und das Verfahren, mit dem geprüft wird, ob Daten unterwegs verändert wurden. Browser und Server unterstützen meist mehrere Suiten und müssen sich bei jeder Verbindung auf eine einigen.

Bevor eine HTTPS-Verbindung überhaupt verschlüsselt läuft, findet ein kurzer, unverschlüsselter Aushandlungs-Dialog statt: der TLS-Handshake. Dabei schickt der Browser zuerst ein ClientHello, das im Klartext auflistet, welche Cipher Suites er kennt und zwar in einer ganz bestimmten Reihenfolge, die von der TLS-Bibliothek im Browser abhängt (Chrome nutzt z. B. BoringSSL, Firefox NSS). Diese Reihenfolge ist software-spezifisch wie ein Dialekt. Sie verrät oft genauer als der leicht fälschbare User-Agent-Header, welcher Browser tatsächlich anfragt.

Diese Liste lebt allerdings auf der TCP/TLS-Paketebene, unterhalb von HTTP. PHP bekommt vom Webserver nur das fertige Verhandlungsergebnis übergeben, nicht die ursprüngliche Reihenfolge. Um sie zu sehen, bräuchte man Zugriff auf die rohen Netzwerkpakete oder ein spezialisiertes Modul, das daraus einen sogenannten JA3-Hash bildet. Diese zusätzliche Infrastruktur bringt dieses Tool jedoch bewusst nicht mit.

Zur Veranschaulichung: Stellen Sie sich zwei Menschen vor, die sich etwas zuflüstern wollen. Bevor es losgeht, verständigen sie sich kurz: „Ich kann Geheimsprache A, B oder C, in dieser Reihenfolge bevorzugt. Verstehst du A?“
Diese kurze Eröffnungsfloskel folgt einem festen Schema, das von der „Schule“ abhängt, in der jemand das Flüstern gelernt hat. Selbst wenn die Person hinterher behauptet, jemand ganz anderes zu sein, verrät sie sich schon durch die Art, wie sie die Eröffnung führt. Dies geschieht genauso, wie ein Browser sich durch die Reihenfolge seiner Cipher-Liste verrät, ganz gleich, was im User-Agent-Header steht.