Post-Quanten-TLS 2026: Warum das übereinstimmende JA4 Scraper nicht mehr rettet

Vor einem Jahr war das Schema klar: Man nimmt einen Kunden, der in der Lage ist, ein TLS-Handshake zu fälschen, wählt ein Profil für den aktuellen Chrome aus, erhält einen übereinstimmenden JA4 – und der Anti-Bot lässt durch. Im Jahr 2026 begann dieses Rezept aus Gründen, die nichts mit dem „Umgehen von Schutzmaßnahmen“ zu tun haben, zu versagen. Browser sind massenhaft auf post-quanten Schlüsselübergabe umgestiegen, während die meisten Scraping-Stacks das nicht getan haben. Und nun ist das Fehlen einer post-quanten Schlüsselübergabe an sich ein Kennzeichen der Automatisierung.

Schauen wir uns die Kriterien an: Was genau hat sich im Handshake geändert, welche Stacks sind bereits umgestiegen, welche nicht, und warum ist ein übereinstimmender JA4 nicht mehr ausreichend.

Was passiert ist: Post-quanten Schlüsselübergabe ist zur Norm geworden, nicht zur Exotik

Die hybride post-quanten Schlüsselübergabe ist eine Kombination aus der klassischen elliptischen Kurve X25519 und dem Gitter-basierten Mechanismus ML-KEM (NIST FIPS 203 Standard). Die Sitzung bleibt geschützt, wenn mindestens einer der beiden Komponenten robust bleibt. Der Sinn dahinter ist der Schutz vor dem Szenario „jetzt abfangen, später entschlüsseln“, bei dem der Verkehr archiviert wird in der Erwartung eines zukünftigen Quantencomputers.

Chronologie der Implementierung in Clients:

• Chrome 124 (April 2024) – hybride post-quanten Schlüsselübergabe ist standardmäßig aktiviert; in den Patches curl-impersonate ist dies als „Kurven X25519Kyber768/X25519MLKEM, eingeführt in Chrome 124 und 130“ vermerkt.
• Firefox 132 (November 2024) – Unterstützung ist aktiviert.
• Safari auf iOS und macOS – die post-quanten Schlüsselübergabe kam im Oktober 2025.
• OpenSSL 3.5.0 (April 2025) – hybride Gruppen X25519MLKEM768, SecP256r1MLKEM768 und SecP384r1MLKEM1024 wurden in die Standardgruppe für TLS aufgenommen.
• Go 1.24 (Februar 2025) – X25519MLKEM768 ist standardmäßig in crypto/tls aktiviert, wenn Config.CurvePreferences nicht ausdrücklich festgelegt ist.

Von der Infrastrukturseite aus ist das Bild noch deutlicher. Cloudflare Radar zeigte im April 2026 etwa 67% des menschlichen HTTPS-Verkehrs mit post-quanten Verschlüsselung – im Vergleich zu 32% im Januar 2025. Akamai machte die post-quanten Schlüsselübergabe zum Standard für alle Client-Verbindungen am 31. Januar 2026 und schloss die Ausrollung im März ab. Laut Branchenmessungen sind bereits etwa 57,4% aller Browser-Transaktionen post-quanten-fähig, wobei der Anteil der PQ-fähigen Chrome-Browser bei etwa 93% liegt.

Beachten Sie die Asymmetrie: Die Unterstützung auf der Seite der Origin-Server wächst viel langsamer (bei Cloudflare etwa 9%). Das heißt, post-quanten-fähig zu sein, ist heute in erster Linie ein Merkmal des Clients. Genau das ist für den Anti-Bot von Interesse.

Kriterium 1: Größe der Schlüsselübergabe und Struktur von ClientHello

Die post-quanten Schlüsselübergabe ist kein „noch ein Häkchen in der Erweiterung“. Sie ist physisch groß: etwa 1124 Byte im Vergleich zu 36 Byte bei der klassischen X25519. Die Folgen sind mit bloßem Auge auf Paketebene sichtbar.

ClientHello mit post-quanten Schlüsselübergabe überschreitet 1400 Byte und passt nicht mehr in ein TCP-Segment. Es wird in zwei oder mehr Pakete aufgeteilt. Und dann beginnt das Interessanteste für die Erkennung: das Fragmentierungsmuster ist bei verschiedenen Implementierungen unterschiedlich. Wie genau der Stack das große ClientHello aufteilt, in welcher Reihenfolge die Segmente gesendet werden und mit welchen Timings – das ist beobachtbares Verhalten, das sich nicht aus dem JA4-Hash ableitet und das fast niemand der Autoren von Scraping-Tools bewusst reproduziert.

Praktische Schlussfolgerung: Der Anti-Bot hat eine Schicht, die unter dem gewohnten Fingerabdruck arbeitet. Sie können eine Liste von Chiffren und Erweiterungen perfekt zusammenstellen, aber sich selbst verraten, wie Ihr Stack Bytes in den Socket legt.

Kriterium 2: Konsistenz mit der angegebenen Browser-Version

Die Hauptfalle des Jahres 2026 ist die Desynchronisation zwischen dem, was Sie vorgeben, und dem, was Ihr TLS-Stack tatsächlich tut.

Anti-Bot-Plattformen halten Datenbanken mit Referenz-ClientHello. Eine Anfrage, die im User-Agent und im JA4 Chrome 131 angibt, aber ohne post-quanten Schlüsselübergabe ankommt, stimmt mit keinem bekannten gültigen Chrome 131 überein. Das ist nicht „verdächtig“ – das ist logisch unmöglich. Ein echter Chrome dieser Version kann physisch keinen klassischen Schlüsselübergabe bei den Standardeinstellungen senden.

Wie gut dies durch maschinelles Lernen getrennt wird, wurde ebenfalls ermittelt. Der CatBoost-Klassifikator zeigt in Studien mit JA4-Features AUC 0,998 und Genauigkeit 0,9863; separat unterscheidet sich der post-quanten Verkehr vom klassischen mit einer Genauigkeit von etwa 98%. Das ist keine „Heuristik mit Fehlalarmen“, das ist ein praktisch deterministisches Merkmal.

Kriterium 3: Bereitschaft bestimmter Stacks

Hier verläuft die echte Trennlinie. Lassen Sie uns in Gruppen aufteilen.

Versenden PQ Schlüsselübergabe standardmäßig

• Chrome 124+, Firefox 132+, Safari (iOS/macOS seit Oktober 2025) – das Referenzmodell, mit dem Sie verglichen werden.
• Go 1.24+ – crypto/tls aktiviert X25519MLKEM768 selbst, wenn Sie CurvePreferences nicht überschrieben haben. Wichtiger Hinweis: Es gibt post-quanten-fähigkeit, aber JA4 bei einem nackten Go-Client ist trotzdem kein Browser-Fingerabdruck. Sie erhalten einen „PQ-kompatiblen, aber nicht wie Chrome aussehenden“ Fingerabdruck.
• Node.js 24 – bringt sein eigenes OpenSSL 3.5 mit, sodass die Standardgruppe bereits hybride enthält. Außerdem wurden in node:crypto ML-KEM über crypto.encapsulate()/decapsulate() und ML-DSA in sign()/verify() hinzugefügt.

Hängen davon ab, woran sie gebunden sind

• Python: requests, aiohttp, httpx – verwenden das ssl-Modul, das das systemweite OpenSSL verwendet. Auf Ubuntu 24.04 lebt OpenSSL 3.0.x im System, wo es keine post-quanten Gruppen gibt. Um PQ zu erhalten, muss OpenSSL 3.5 aus den Quellen kompiliert, über LD_LIBRARY_PATH eingebunden und wahrscheinlich Python selbst neu kompiliert werden. In der Praxis bedeutet das: typische Python-Scraper senden im Jahr 2026 einen klassischen Schlüsselübergabe und erscheinen bei Akamai als Anomalie.

Können, aber nur wenn das richtige Profil gewählt wird

• curl_cffi / curl-impersonate – Unterstützung für post-quanten Kurven im Fork ist vorhanden und ausdrücklich angegeben. Aber die Liste der Targets reicht von chrome99 bis chrome146 (im Fork bis chrome150), und alte Profile reproduzieren das Handshake ihrer Zeit, also ohne PQ. Copy-Paste impersonate="chrome116" aus einem zwei Jahre alten Leitfaden ist der direkte Weg zur Erkennung.
• uTLS – das gleiche Prinzip: Profile HelloChrome unter 131 enthalten keine PQ Schlüsselübergabe. Außerdem wurden in der Bibliothek für das Jahr 2026 zwei Fingerabdruckanfälligkeiten geschlossen: CVE-2026-26995 (Versionen 1.6.0–1.8.1) und CVE-2026-27017 (1.6.0–1.8.0, Desynchronisation der Chiffrauswahl für GREASE ECH – Chrome wählt sie deterministisch, während parrot in uTLS zwischen AES und ChaCha20 zufällig wählte, was für echten Chrome unmöglich ist). Aktualisieren Sie mindestens auf 1.8.2.

Der gemeinsame Nenner: Die Tools haben größtenteils aufgeholt. Das Problem liegt nicht bei ihnen, sondern darin, dass Konfigurationen schneller veralten als Browser. Ein Profil, das 2024 ideal war, funktioniert heute als Marker.

Wie man seinen Stack in fünf Minuten überprüft

1. Schicken Sie eine Anfrage mit Ihrem Produktionsclient an https://tls.peet.ws/api/all oder ja4db.com – sie geben lebendige JA3/JA4 und die Analyse von ClientHello im JSON-Format zurück.
2. Finden Sie in der Analyse die Liste der supported_groups und key_share. Suchen Sie nach X25519MLKEM768 (oder X25519Kyber768 bei alten Profilen). Wenn dort nur x25519/secp256r1 steht – gibt es keine post-quanten Schlüsselübergabe.
3. Vergleichen Sie dies mit der Version des Browsers, die Sie vorgeben. Geben Sie Chrome 131+ an und sehen keine PQ-Gruppen – die Kombination ist ungültig, reparieren Sie das Profil.
4. Überprüfen Sie die Größe von ClientHello. Weniger als ~1400 Byte bei angegebenem aktuellem Chrome – das ist dasselbe Zeichen, nur von der anderen Seite.
5. Führen Sie die Überprüfung von jedem Ausgangsknoten aus durch, nicht nur von der Arbeitsmaschine: SSL-Inspektion am Unternehmensgateway oder beim Anbieter kann das Handshake für Sie umschreiben.

Was Proxy hier tun

Es ist wichtig, zwei unabhängige Schichten nicht zu vermischen. Die post-quanten Schlüsselübergabe betrifft das Handshake, der Ruf der Adresse betrifft das Netzwerk. Der Anti-Bot betrachtet sie separat und summiert sie.

Hieraus ergeben sich zwei praktische Folgerungen. Erstens: Eine ideale Residential-IP wird keine Anfrage retten, die sich auf TLS-Ebene als Chrome 131 ohne PQ-Gruppe ausgibt – Sie verlieren, noch bevor der Server die Adresse betrachtet. Zweitens, spiegelbildlich: Ein korrekt durchgeführtes post-quanten Handshake hilft nicht, wenn Hunderte Ihrer Sitzungen aus einem Subnetz eines Rechenzentrums mit beschädigtem Ruf kommen. Beide Schichten müssen repariert werden, und sie werden mit unterschiedlichen Werkzeugen repariert.

Praktische Aufschlüsselung nach Aufgaben: Für Ziele hinter Akamai und Cloudflare, wo sowohl das Handshake als auch das Netzwerk berücksichtigt werden, ist es sinnvoll, Residential-Proxys zu verwenden und gleichzeitig das Ziel-impersonate auf den aktuellen Chrome zu erhöhen. Für mobile Anwendungen und Plattformen, bei denen das Gewicht der IP-Reputation höher ist als die Anforderungen an TLS, gewinnen oft mobile Proxys. Und für eigene APIs, Partner-Exporte und interne Überwachungen, wo kein Anti-Bot vorhanden ist, macht es keinen Sinn, für Residential zu überbezahlen – Datacenter-Proxys sind ausreichend.

Wenn Sie sich mit Fingerabdrücken von Grund auf beschäftigen, beginnen Sie mit der Basis: wie JA4 funktioniert und was es umfasst. Und wenn es nicht um einen HTTP-Client, sondern um einen vollwertigen Browser geht, sind die Vergleiche von Stealth-Bauten und deren Schwächen separat gesammelt – nodriver, Camoufox und Patchright in den Messungen 2026.

Fazit

Die post-quanten Schlüsselübergabe wurde nicht als Anti-Bot-Mechanismus gedacht. Sie wurde unbeabsichtigt dazu: Browser sind schnell und massenhaft umgestiegen, die Infrastruktur (Akamai – seit dem 31. Januar 2026) hat sie zum Standard gemacht, und die Scraping-Stacks haben sich in drei Gruppen aufgeteilt – bereits umgestiegen, abhängig vom systemweiten OpenSSL und können nur bei einem aktuellen Profil.

Die Überprüfung reduziert sich auf eine Frage: Sendet Ihr Client X25519MLKEM768 und stimmt dies mit der Version des Browsers überein, die Sie vorgeben. Wenn nicht – wird Sie ein übereinstimmender JA4 nicht retten, denn es wird nicht mehr der Hash verglichen, sondern die gesamte Form des Handshakes: Größe der Schlüsselübergabe, Anzahl der TCP-Segmente und deren Sendereihenfolge. Die gute Nachricht ist, dass dies in den meisten Fällen durch ein Update des Profils und der Bibliotheksversion behoben werden kann, anstatt den Scraper neu zu schreiben.