Zusammenfassung

  • ECH verschlüsselt den privaten ClientHelloInner und trägt ihn in einem öffentlichen ClientHelloOuter zur gemeinsamen TLS-Tür.
  • Der Nutzen hängt an DNS-Konfiguration, Schlüsselbestand, Annahmebestätigung, Wiederholungen und einem äußerlich hinreichend einheitlichen Serververbund.
  • DNS-Anfrage, IP-Adresse und Verkehrskorrelation bleiben mögliche Hinweise; ein vorhandener ech-Parameter ist noch kein Betriebsnachweis.

Der erste Gruß hatte einen sichtbaren Namen

Die Erweiterung server_name aus RFC 6066 löste das Hostingproblem mehrerer Namen auf gemeinsamer Infrastruktur. Da ClientHello nach RFC 8446 die erste TLS-1.3-Nachricht ist, blieb die Auswahl sichtbar, bevor der weitere Handshake geschützt wurde.

RFC 9849, seit März 2026 Standards Track, teilt den Gruß. Der innere Teil enthält den wirklichen SNI und andere empfindliche Werte. Der äußere Teil zeigt öffentliche Werte und transportiert den mit HPKE und einem ECHConfig verschlüsselten inneren Block.

Das Frontend nimmt ECH an und verarbeitet oder leitet den inneren Gruß weiter. Kann es ihn nicht öffnen, arbeitet es mit dem äußeren und kann aktuelle Wiederholungskonfigurationen liefern. Der Client prüft die Annahme. Eine nach einem ECH-Angebot abgelehnte Verbindung wird nicht für Anwendungsdaten genutzt; Ablehnung ist ein kontrollierter Neubeginn.

Das Frontend erhält eine begrenzte, aber mächtige Rolle

Im gemeinsamen Modus ist die sichtbare Tür zugleich TLS-Endpunkt. Im geteilten Modus entschlüsselt sie nur den inneren Gruß und reicht ihn an ein getrenntes Backend, das TLS beendet. Das Frontend kennt das Routingziel, ohne zwangsläufig den Anwendungsstrom zu terminieren.

DNS-Halter, Client, Frontend und Backend besitzen jeweils einen Teil des Ergebnisses. Die Zone veröffentlicht. Der Client bietet an. Das Frontend hält den privaten Schlüssel. Das Backend bestätigt die innere Transkription. Ein einzelner grüner Status kann diese Kette nicht vertreten.

Auch der Schlüsselbestand ist Teil des Protokolls. Wegen TTL und Caches müssen alte Konfigurationen eine Zeit lang gültig bleiben. Zu kurze Überlappung erzeugt Ablehnungen; zu viele Schlüssel erhöhen Probeentschlüsselung. Schnelle Rotation begrenzt ein Kompromittierungsfenster, kann aber die beobachtbare Gruppe zersplittern.

DNS trägt den Hinweis zum geschützten Handshake

RFC 9848 definiert ech für die SVCB- und HTTPS-Datensätze aus RFC 9460. Sie liefern Endpunkte und Parameter vor dem Verbindungsversuch.

Mischt ein RRSet Ziele mit und ohne ECH, kann ein Angreifer die geschützten Ziele blockieren und nur das ungeschützte übrig lassen. RFC 9848 rät davon ab. Wer die SVCB-Auflösung verhindert, kann außerdem erreichen, dass der Client die Schutzabsicht nie erfährt.

Verschlüsselter DNS-Transport schützt gegen den lokalen Mitleser, nicht gegen die Kenntnis des rekursiven Resolvers. Die Frontend-IP bleibt sichtbar. ECH schützt ein genau benanntes Handshake-Feld; es verspricht keine unsichtbare Verbindung.

Eine Anonymitätsmenge ist eine Betriebseigenschaft

Mehrere Namen müssen Konfiguration und öffentliches Verhalten teilen. Gibt das Frontend jedem Namen einen eigenen Identifikator, kann die Menge auf eins schrumpfen. Auch eindeutige Cipher-Angebote, Erweiterungsreihenfolgen, Record-Grenzen oder Retry-Cookies trennen Mitglieder.

Das Innere kann kryptografisch korrekt und das Äußere trotzdem verräterisch sein. Deshalb muss ein Test mehrere Namen derselben Gruppe vergleichen.

GREASE macht einen Einzelfehler mehrdeutig

GREASE ECH sendet eine glaubhafte Erweiterung, auch ohne echte Konfiguration. So werden intolerante Mittelboxen sichtbar und reales ECH sticht weniger heraus. Ein Entschlüsselungsfehler allein beweist deshalb keine Fehlkonfiguration. Wiederholungslisten, Schleifen und ech_required-Alarme liefern bessere Hinweise.

Grenzen des festen Belegsatzes

Die RFCs belegen Format, Rollen und Schutzziel. Sie belegen weder weltweite Einführung noch das Verhalten eines bestimmten Clients, Resolvers oder Netzes. Die reale Größe einer Anbietergruppe bleibt ohne Messung unbekannt.

Quellen