Der TLS-Handshake ist die Baseline der Bot-Detection
98,6 %.
Das ist die Klassifizierungsgenauigkeit, die ein CatBoost-Modell nur mit JA4-Features erreicht hat. Keine Header. Keine IPs. Kein Verhalten. Nur die Struktur des TLS-Handshakes. Das arXiv-Paper erschien im Februar 2026, und das Ergebnis ist kein Ausreißer. Cloudflare, AWS, VirusTotal und Akamai nutzen alle JA4 (oder den älteren Verwandten JA3) in der Produktion. Wenn du 2026 mit einem einfachen HTTP-Client scrapst, stand das Urteil schon fest, bevor dein Request die Anwendungsschicht erreicht hat.
Das ist der Teil, den Tutorials zur Bot-Detection überspringen. Die meisten Beiträge zur Anti-Bot-Umgehung drehen sich immer noch um User-Agent-Rotation, Cookies und CAPTCHAs. Das sind die einfachen Ebenen. Aber die TLS-Ebene ist diejenige, die du nicht mit einem Header austricksen kannst.
Was JA4 tatsächlich sieht
JA4 ist ein Fingerprint des TLS-ClientHello. Er kodiert das Protokoll (TCP oder QUIC), die TLS-Version, das Vorhandensein von SNI, die sortierten Cipher Suites, Extensions, Signaturalgorithmen und ALPN. Die Ausgabe ist ein kompakter String wie t13d1516h2_8daaf6152771_e5627906d626. Zwei Clients, die vorgeben, derselbe Browser zu sein, erzeugen denselben JA4-Hash. Ein Python-requests-Skript, das sich als Chrome ausgibt, erzeugt ein JA4, das es nirgendwo auf der Welt gibt (außer bei Scrapern).
Die JA4-Familie (entwickelt von FoxIO, derselben Gruppe hinter JA3) hat die größte Schwachstelle von JA3 behoben: die Extension-Permutation, die Chromium 2023 einführte, um einfaches Fingerprinting auszuhebeln. JA4 sortiert Extensions und zählt sie, sodass Randomisierung nicht hilft. Es gibt keinen einfachen Ausweg.
Akamai meldete eine Genauigkeit von 92 bis 98 % bei der Bot-Klassifizierung durch Cross-Layer-Analysen. Der Cross-Layer-Teil ist entscheidend. TLS allein ist das dominierende Signal, aber die Kombination mit HTTP/2-Frame-Reihenfolge, Header-Reihenfolge und Request-Timing drückt die False-Positive-Rate weit unter das Niveau, das die meisten Scraper tolerieren können.
Der Post-Quantum-Twist
Das ist der Teil, den niemand hat kommen sehen. Am 31. Januar 2026 hat Akamai den Post-Quantum-Schlüsselaustausch standardmäßig aktiviert für alle Verbindungen. Bis Anfang 2026 enthielten 57,4 % der echten, vom Browser initiierten Verbindungen den X25519MLKEM768-Key-Share. Der PQ-fähige Anteil von Chrome liegt bei etwa 93 %. Firefox 132 liegt bei 85 %. Safari zieht gerade nach.
Der PQ-Key-Share ist groß. 1.124 Bytes im Vergleich zu 36 Bytes beim klassischen X25519. Das ClientHello wuchs von 300 bis 500 Bytes auf über 1.400 Bytes an. Dieses Wachstum zeigt sich in JA4, im Packet-Capture und bei der passiven Beobachtung an der WAF.
Wenn dein Scraping-Client den PQ-Key-Share nicht enthält, behauptest du etwas, das kein aktueller Chrome oder Firefox tun würde. Zwei CVEs aus dem ersten Quartal 2026 markieren genau diese Diskrepanz: CVE-2026-26995 (Padding-Extension) führt zu einer Erkennungswahrscheinlichkeit von 25 bis 50 % pro Request, und CVE-2026-27017 (ECH- und GREASE-Diskrepanz) liegt bei etwa 50 %. Über eine Session hinweg steigt das Risiko fast bis zur Gewissheit.
Aus einem 12-Monats-Problem wird hier ein 3-Monats-Problem. Die meisten Open-Source-Scraping-Stacks bieten noch kein PQ-kompatibles TLS. Diejenigen, die es tun, hinken dem echten Chromium um Wochen hinterher.
Warum Proxies das nicht lösen
Es kursiert die beruhigende Geschichte, dass größere Proxy-Pools die moderne Bot-Detection aushebeln. Das tun sie nicht. Der Scalping-Vorfall im Januar 2026, über den Security Boulevard berichtete, nutzte 16 Millionen Requests über 3,9 Millionen eindeutige IPs. Ein Blockieren pro IP war nutzlos. Die Verteidigung, die funktionierte, basierte größtenteils auf TLS und verhaltensbasiertem Fingerprinting.
Auch die Wirtschaftlichkeit von Residential Proxies ist in diesem Quartal eingebrochen. Help Net Security berichtete im April 2026, dass die Zerschlagung des IPIDEA-Netzwerks im Januar die weltweite Residential-Kapazität über Nacht um rund 40 % reduzierte. Der Patentstreit zwischen Bright Data und Oxylabs (der Supreme Court wies die Petition von Bright Data am 23. Februar 2026 ab, der Prozess ist für den 18. Mai angesetzt) ist im Vergleich zu diesem Kapazitätsverlust nur ein Nebenschauplatz. Käufer, die auf Residential IPs als Schutz gegen Fingerprinting setzen, zahlen mehr für eine Lösung, die der WAF völlig egal ist.
Proxies sind immer noch wichtig, nur nicht aus dem Grund, den die meisten vermuten. Geografische Verteilung und ISP-Typ beeinflussen Routing-Entscheidungen und Rate-Limit-Profile. Sie helfen dir aber nicht, den Handshake zu überleben.
Was das für Datenteams bedeutet
Drei Dinge ändern sich, wenn du 2026 Scraping-Infrastruktur aufbaust oder kaufst.
Erstens ist der TLS-Stack jetzt eine harte Voraussetzung. Jeder Client, der den TLS-Handshake eines echten Browsers nicht imitiert (PQ-Key-Share, Extension-Reihenfolge, ALPN, Signaturalgorithmen), erzeugt einen Fingerprint, der mit hoher Sicherheit als Bot eingestuft wird. Das Verpacken von Python-requests in bessere Header löst gar nichts. Der Transport verrät dich.
Zweitens ist die Erkennung von Headless-Browsern schwieriger geworden, nicht einfacher. Der State of Web Scraping 2026 von Browserless berichtet, dass sich die Lücke zwischen Headless- und Headed-Chromium vergrößert. Anti-Bot-Anbieter haben die Fingerprint-Unterschiede katalogisiert und teilen Bedrohungsdaten (Threat Intel) nahezu in Echtzeit über Kundenseiten hinweg. Eine Headless-Instanz, die im Dezember noch funktionierte, wird im Mai vielleicht als Bot eingestuft. Die Verhaltenssignale bauen auf TLS auf, und beide sind bewegliche Ziele.
Drittens hat sich die Build-vs-Buy-Rechnung verschoben. Einen TLS-Fingerprint zu pflegen, der einem beweglichen Ziel folgt (Chromium liefert alle paar Wochen PQ-Updates aus, die Extension-Reihenfolge ändert sich zwischen Minor-Versionen, Cipher-Suite-Präferenzen verschieben sich), ist mittlerweile ein Vollzeitjob. Teams, die 2024 noch 20 % einer Entwicklerstelle für die Scraper-Wartung aufgewendet haben, investieren 2026 mehr als eine halbe Vollzeitstelle. Wir haben schon früher darüber geschrieben, warum Web-Scraper ständig kaputtgehen. Im Jahr 2026 lautet die Antwort viel häufiger „TLS“ als „DOM“.
Der günstigste Scraper ist der, der nicht klassifiziert wird
Die spannende Frage ist nicht, ob Anti-Bot-Anbieter die Messlatte weiter höher legen. Das werden sie tun. Die spannende Frage ist, welche Scraping-Tools in einem Markt überleben, in dem eine Genauigkeit von 98 % die absolute Grundvoraussetzung für die Erkennung ist.
Die meisten werden es nicht schaffen. Aber diejenigen, die es tun, werden den TLS-Handshake als Teil des Requests behandeln, nicht als Transportdetail. Und Käufer werden Anbietern eine Frage stellen, die vor zwölf Monaten noch nicht auf der Checkliste stand: Welchen TLS-Fingerprint liefert ihr und wie schnell aktualisiert ihr ihn?
Der Handshake entscheidet alles, noch bevor der Request überhaupt die Chance hat, sein Anliegen vorzubringen.