Zusammenfassung

  • Verschlüsseltes ClientHelloInner, Außenhülle und das public_name des clientseitigen Servers sind getrennte Tatsachen. Der öffentliche Name ist nicht der Name des privaten Backends.
  • DNS-Konfiguration, ECH-Annahme, TLS-Validierung und Anwendungserfolg brauchen eigene Nachweise; keine Ebene erbt das Urteil einer anderen.

RFC 9849 legt private Werte in ClientHelloInner und unkritische Werte samt ECH-Erweiterung in ClientHelloOuter. Der Client verschlüsselt das Innere mit einem öffentlichen ECH-Schlüssel und bindet Innen- und Außenseite über zusätzliche authentifizierte Daten. Das verhindert eine bestimmte Manipulation der Hülle. Es sagt nicht, dass DNS-Eintrag, öffentliche Adresse, Frontend-Anbieter, Backend und Anwendungsprinzipal derselbe Akteur sind.

Auch public_name hat eine engere Aufgabe als sein Name nahelegt. Es ist der DNS-Name des clientseitigen Servers, dem im ECH-Modell das Aktualisieren der Konfiguration und die Wiederherstellung bei veralteter Konfiguration anvertraut sind. Üblicherweise erscheint er im äußeren SNI. Er ist eine öffentliche Routing- und Wiederherstellungsfläche, nicht der verborgene Ursprungsname, kein Eigentumsnachweis und kein Identitätsurteil über alle privaten Namen.

Die Topologien machen diesen Vorbehalt praktisch. Im Shared Mode können Frontend und TLS-Terminierung zusammenfallen. Im Split Mode leitet der clientseitige Server an ein Backend weiter, das TLS terminiert, ohne dass das Frontend den Klartext erhält. Der RFC setzt einen authentisierten Kanal zwischen beiden voraus und setzt voraus, dass Angreifer die zwei Strecken nicht korrelieren können; den genauen Schutzmechanismus legt er nicht fest. Ein beobachtetes ECH prüft diese Betriebsannahmen nicht.

Die Annahme von ECH bleibt ebenfalls ein schmaler Handshake-Fakt. Ein Server nimmt ECH an und verwendet das Innere oder lehnt es ab und verwendet das Äußere. Nach einer Ablehnung ist die Verbindung für Anwendungsdaten des ECH-Clients nicht nutzbar und kann eine Wiederholung mit aktueller Konfiguration auslösen. Eine Annahme belegt nicht, dass der lokale Trust Store die Zertifikatskette akzeptiert hat, der erwartete Name passte, die Anwendung eine Aktion autorisierte oder ein Auftrag erfolgreich war.

RFC 8446 trennt TLS von der Anwendungssemantik: TLS handelt Parameter aus, kann Peers authentisieren und erzeugt Schlüssel. Vertrauensanker und detaillierte Zertifikatsprüfung sind eigene Entscheidungen. RFC 9460 lässt SVCB/HTTPS öffentliche Schlüssel und alternative Endpunkte mit unterschiedlichen Fähigkeiten oder Betreibern übermitteln. Ein DNS-Record beschreibt eine mögliche Client-Anweisung, nicht den tatsächlich gewählten Terminator oder das Resultat eines Dienstes.

Für eine belastbare Untersuchung bleiben deshalb Quelle und TTL der ECHConfig, Resolver und Cache, Annahme/Ablehnung, erwartete Identität und Validierung, Frontend-Backend-Kanal, gewählter Endpunkt und Anwendungsergebnis in getrennten Spalten. Ein verschlüsseltes Paket kann eine Spalte erhellen, aber nicht die anderen ausfüllen.

Quellen