ECH aktiviert, aber SNI ist immer noch sichtbar: wie man 2026 überprüft

```html

ECH — die Verschlüsselung des Domainnamens im TLS-Handshake — erhielt im März 2026 den Status eines Standards (RFC 9849, Standards Track). Firefox und Chrome aktivieren es standardmäßig, Cloudflare verteilt die Schlüssel an fast alle seine Kunden. Dabei funktioniert ECH bei den meisten Nutzern stillschweigend nicht: der Browser wechselt zum normalen Handshake, und der Anbieter sieht weiterhin, wohin Sie gehen.

Im Folgenden erfahren Sie, wie Sie in einer Minute selbst überprüfen können, ob SNI bei Ihnen verschlüsselt ist, warum es meistens nicht verschlüsselt ist und in welchen Szenarien ECH prinzipiell nutzlos ist (Spoiler: für Anti-Detection und Parsing — fast immer).

Was genau verbirgt ECH — und was nicht

In einem normalen TLS 1.3 ist alles verschlüsselt, außer der ersten Nachricht — ClientHello. Darin befindet sich im Klartext das SNI-Feld mit der Domain, zu der Sie eine Verbindung herstellen. Genau auf Basis des SNI arbeiten die meisten Filtersysteme: die IP ist eine von Tausenden von Websites hinter einem CDN, und die Domain ist sichtbar.

ECH teilt ClientHello in zwei Teile:

ClientHelloOuter — wird offen übertragen, jedoch mit einer gefälschten Wrapper-Domain. Bei Cloudflare ist das cloudflare-ech.com.
ClientHelloInner — die echte Domain, ALPN und die Liste der Cipher, verschlüsselt mit dem öffentlichen Schlüssel des Servers.

Der Schlüssel für diese Verschlüsselung wird vom Browser nicht aus der Verbindung, sondern aus dem DNS entnommen — aus dem HTTPS-Eintrag (Typ 65), Parameter ech=. Daraus folgt die wichtigste Konsequenz, die oft vergessen wird: ECH ist ohne verschlüsseltes DNS unmöglich. Wenn die DNS-Anfrage unverschlüsselt über UDP/53 erfolgt, sieht der Beobachter den Domainnamen bereits vor dem Handshake, und der filternde Resolver kann den Parameter ech= aus der Antwort entfernen — und ECH wird nicht aktiviert.

Was ECH überhaupt nicht verbirgt:

Die Ziel-IP-Adresse — immer sichtbar;
Das Volumen und die Timings des Traffics;
Der TLS-Fingerabdruck des Clients (JA3/JA4) — die Cipher und Erweiterungen bleiben im offenen Teil;
Sie selbst für die Website — der Server sieht nach der Entschlüsselung alles, was er vorher gesehen hat.

Der letzte Punkt ist der Grund, warum ECH nichts mit dem Umgehen von Anti-Bot-Systemen zu tun hat. Cloudflare, DataDome und Akamai arbeiten auf der Serverseite: es ist ihnen egal, ob das SNI auf dem Weg verschlüsselt wurde. Wenn das Ziel darin besteht, bei der Automatisierung nicht aufzufallen, funktioniert eine ganz andere Schicht: das Fälschen des TLS-Fingerabdrucks, worüber wir im Material über Umgehung des JA4-Fingerabdrucks über curl-cffi gesprochen haben.

Überprüfung Nr. 1: Funktioniert ECH gerade jetzt (10 Sekunden)

Öffnen Sie im Browser:

https://crypto.cloudflare.com/cdn-cgi/trace

Finden Sie die Zeile sni=. Es gibt zwei Möglichkeiten:

sni=encrypted — ECH funktioniert, der Domainname ist auf dem Weg verborgen;
sni=plaintext — ECH wurde nicht angewendet, die Domain wurde im Klartext übertragen.

Die gleiche Adresse über curl im Terminal gibt immer sni=plaintext zurück — normaler curl kann ECH nicht, und das ist ein praktischer Anhaltspunkt: so sieht „ausgeschaltet“ aus.

Überprüfung Nr. 2: Hat die Domain einen ECH-Schlüssel (dig, ohne Browser)

ECH wird nur aktiviert, wenn die Domain im DNS einen HTTPS-Eintrag mit dem Parameter ech= hat. Überprüfen Sie den Rohdatensatz:

dig +short TYPE65 example.com @1.1.1.1

Im Antwort suchen Sie nach den Bytes FE0D — das ist der Code für die ECH-Erweiterung, gefolgt von ECHConfig. Praktisches Beispiel: zum Zeitpunkt der Erstellung des Materials hat crypto.cloudflare.com und unsere Domain proxycove.com einen Eintrag von 133–136 Bytes, der sowohl FE0D als auch den gefälschten Namen cloudflare-ech.com in hexadezimaler Form enthält. Bei cloudflare.com hingegen ist der Eintrag kurz, 61 Bytes: nur ALPN und IP-Hinweise, ohne ECH. Das bedeutet, dass selbst innerhalb der Cloudflare-Infrastruktur ECH nicht an alle Domains verteilt wird — wundern Sie sich nicht, wenn eine bestimmte Website es nicht hat.

Wenn dig sich beschwert ignoring invalid type HTTPS — Sie haben eine alte Version des Tools, verwenden Sie die numerische Form TYPE65, wie im vorherigen Befehl.

Warum ECH bei Ihnen nicht aktiviert wird: fünf Gründe der Reihe nach

Verschlüsseltes DNS ist deaktiviert. Ohne DoH erhält der Browser ECHConfig nicht in vertrauenswürdiger Form. In Firefox: Einstellungen → Datenschutz → DNS über HTTPS im Modus „Erhöht“ oder „Maximaler Schutz“. In Chrome: Einstellungen → Sicherheit → Sicheren DNS verwenden.
Die Domain hat einfach keinen HTTPS-Eintrag mit ech= — dies wird mit dem Befehl aus dem vorherigen Abschnitt überprüft. Hier hängt nichts von Ihnen ab, das ist die Entscheidung des Website-Besitzers und seines CDN.
Der Resolver schneidet den Parameter heraus. Unternehmens- und Provider-DNS-Server können standardmäßig HTTPS-Einträge ohne ech= zurückgeben. Überprüfen Sie dies, indem Sie den Eintrag direkt bei einem öffentlichen Resolver (@1.1.1.1) anfordern und mit der Antwort des systemeigenen Resolvers vergleichen.
Die Browser-Flags wurden zurückgesetzt. In Firefox sind network.dns.echconfig.enabled und network.dns.http3_echconfig.enabled in about:config — beide sollten true sein.
Ein überwachendes Gateway steht dazwischen. Darüber handelt der nächste Abschnitt.

Wie ECH gebrochen wird: zwei verschiedene Szenarien

Unternehmensfirewall: leise Herabstufung

Netzwerkausrüstungsanbieter haben fertige Rezepte gegen ECH veröffentlicht — sie sind nicht bereit, die Sichtbarkeit des Traffics zu verlieren. Cisco zum Beispiel definiert seit der Anwendungsversion VDB 416 (Oktober 2025) „ECH-Server“ als separate Anwendung und bietet zwei Ansätze an: das Abfangen der Verbindung mit der Rekonstruktion des Zertifikats und das Herausnehmen der Erweiterung encrypted_client_hello aus ClientHello, oder einfacher — auf DNS-Ebene: Blockieren von HTTPS-Einträgen für ECH-Domains, Schneiden von DoH/DoT/DoQ, Blockieren der Canary-Domain use-application-dns.net und Erlauben von DNS nur auf Unternehmensserver.

Die List der ersten Methode besteht darin, dass sie nicht wie eine Blockierung aussieht. Der Server, der die ECH-Erweiterung nicht sieht, antwortet wie gewohnt, der Client betrachtet ECH als „sicher deaktiviert“ und verbindet sich dann mit offenem SNI. Die Website öffnete sich, es gibt keine Fehler — und der Domainname ist im Protokoll des Gateways gelandet.

Staatliche Ebene: Die Verbindung stirbt einfach

Das russische Beispiel ist in seiner Genauigkeit bemerkenswert. Ab dem 5. November 2024 tritt die Filterung nur dann in Kraft, wenn zwei Merkmale gleichzeitig übereinstimmen: SNI mit dem Wert cloudflare-ech.com plus das Vorhandensein der ECH-Erweiterung. Einzelne Merkmale lösen keine Blockierung aus — ECH funktioniert für andere Wrapper-Domains (z.B. Testdomains defo.ie oder tls-ech.dev). Dies wird nicht durch das Zurücksetzen der Verbindung, sondern durch leises Verwerfen von Paketen realisiert: die Seite hängt und bricht nach einer Zeitüberschreitung ab. Betroffen sind sowohl TCP-basiertes HTTP/2 als auch QUIC/HTTP-3. Roskomnadzor erklärte damals direkt, dass die Verwendung von TLS ECH gegen das russische Gesetz verstößt, und empfahl den Website-Besitzern, von Cloudflare CDN abzuwandern — Tausende von völlig legalen Ressourcen, die in die allgemeine Wrapper gefallen sind, wurden auf einmal gefiltert.

Firefox versucht in einer solchen Situation etwa nach einer Minute erneut, jedoch ohne ECH — das bedeutet, dass letztendlich offenes SNI zurückgegeben wird, was die Spezifikation aus Sicherheitsgründen nicht empfiehlt. Wenn Sie beobachten, dass „die Website genau eine Minute lädt und dann öffnet“ — ist das fast sicher der Fall.

Wann ECH nicht ausreicht und was stattdessen eingesetzt werden sollte

Schauen wir uns die Aufgaben ehrlich an.

Privatsphäre vom Anbieter im Heimnetzwerk. ECH + DoH — eine gute und kostenlose Verbesserung. Funktioniert dort, wo es nicht geschnitten wird.
Umgehung von Filtern. ECH wurde dafür nicht entworfen, und die Praxis hat dies bestätigt: Sobald es anfängt, die Filter zu stören, haben sie gelernt, es zu erkennen und vollständig zu blockieren. Man kann sich nicht auf es als Zugangsinstrument verlassen.
Parsing, Multi-Accounting, Automatisierung. ECH bietet nichts: die Zielwebsite sieht Ihre IP, Ihr JA4 und Ihre Anfragehistorie. Nur die Quell-IP und die Qualität des Fingerabdrucks sind von Bedeutung.

In allen Fällen, in denen ECH nicht funktioniert, gibt es eine gröbere, aber zuverlässige Schicht: das TLS-Handshake außerhalb des beobachtbaren Netzwerks zu verlagern. Wenn der Traffic über einen Proxy geht, sieht der Beobachter auf Ihrem Kanal nur die Verbindung zum Proxy-Knoten — es gibt überhaupt kein SNI der Zielwebsite, unabhängig davon, ob die Domain ECH unterstützt oder nicht. Für den täglichen Zugang und die Arbeit mit Diensten, die empfindlich auf die IP-Reputation reagieren, sind residential Proxies geeignet; für mobile Anwendungen und Plattformen, die besonders wählerisch hinsichtlich des Verbindungstyps sind, — mobile.

Und vergessen Sie nicht das DNS: ein Proxy im Browser garantiert nicht, dass die Namen auch über ihn aufgelöst werden. Ein DNS-Leck gibt genau das preis, was Sie zu verbergen versucht haben — wie man dies überprüft, haben wir in einer separaten Anleitung über die Überprüfung von Proxies auf DNS-Lecks behandelt. Wenn es jedoch um die tiefgehende Analyse des Traffics auf dem Kanal geht, sollte man nicht auf ECH schauen, sondern auf den Transport selbst.

Kurze Checkliste

Öffnen Sie crypto.cloudflare.com/cdn-cgi/trace und schauen Sie sich die Zeile sni= an.
Wenn plaintext — aktivieren Sie DoH im Browser und überprüfen Sie erneut.
Hat nicht geholfen — überprüfen Sie das Vorhandensein des Schlüssels bei der Domain: dig +short TYPE65 domain @1.1.1.1, suchen Sie nach FE0D.
Der Schlüssel ist vorhanden, aber ECH wird nicht angewendet — vergleichen Sie die Antworten der öffentlichen und systemeigenen Resolver: höchstwahrscheinlich wird der Parameter auf dem Weg herausgeschnitten.
Die Verbindung hängt eine Minute und öffnet sich — ECH wird auf Netzwerkebene blockiert; ECH hilft hier nicht, ein anderer Transport ist erforderlich.

Fazit

ECH ist das sorgfältig geschlossene letzte Loch in der Privatsphäre von TLS, kein Zugangsmittel und erst recht kein Werkzeug für die Automatisierung. Es hängt von verschlüsseltem DNS ab, wird in der Mitte ohne eine einzige Fehlermeldung auf dem Bildschirm deaktiviert und wird vollständig blockiert, wo es anfängt zu stören. Es lohnt sich, es zu überprüfen — die zwei oben genannten Befehle dauern eine Minute. Aber es ist sinnlos, darauf zu bauen, um Blockaden zu umgehen oder sich vor Anti-Bot-Systemen zu schützen: diese Aufgaben werden auf der Ebene gelöst, dessen IP und dessen TLS-Fingerabdruck der Server am anderen Ende sieht.