Zusammenfassung

  • TLS server_name ist ein vom Client im ClientHello gesetzter DNS-Name, der früh einen Kontext, ein Zertifikat oder Passthrough-Ziel eingrenzt. Er ist kein Client-Nachweis.
  • Service-Identitätsprüfung, HTTP Host/:authority, Upstream-SNI, ECH-Ansicht und Anwendungsberechtigung bleiben getrennte Entscheidungen, selbst bei gleichem Textwert.

Die Auswahl funktionierte, die Schlussfolgerung nicht

Ein anonymer Client sendete tenant-a.example. Der Callback wechselte in den vorgesehenen SSL_CTX, der Server präsentierte das richtige Zertifikat und TLS 1.3 endete erfolgreich. Danach kopierte eine Integration das Kontext-Label als Tenant-Principal in die Anwendung.

SNI löst ein Timing-Problem virtueller Dienste: Der Server braucht vor dem Senden seines Zertifikats einen Hinweis auf das gewünschte Ziel. Der Hinweis kommt vom Client. Wer ein ClientHello erzeugen kann, kann auch einen syntaktisch gültigen, besonders interessanten Namen einsetzen.

Das Zertifikat unterstützt die Authentisierung des Servers gegenüber dem prüfenden Client. Es authentisiert nicht den Client gegenüber dem Server. Aus einer korrekten Auswahl wurde ohne neuen Beleg eine Berechtigung.

Strenge Syntax ist keine Verfügungsgewalt

RFC 6066 definiert eine ServerNameList im ClientHello. Der standardisierte Typ host_name enthält einen DNS-Hostnamen in ASCII; literale IPv4- oder IPv6-Adressen sind ausgeschlossen. Derselbe Namenstyp darf nicht doppelt vorkommen.

Diese Regeln sichern Interoperabilität. Sie belegen weder DNS-Auflösung noch Zonenverwaltung, Schlüsselbesitz, Vertrag oder Tenant-Zugehörigkeit. Ein Diagnoseprogramm kann eine feste Adresse verbinden und einen anderen Namen senden. Ein Angreifer kann das ebenso.

Bei einem verstandenen, aber abgelehnten Namen kann der Server fatal mit unrecognized_name abbrechen. Eine definierte Rückfallkonfiguration kann ebenfalls zulässig sein. Deshalb müssen fehlendes, unbekanntes und ungültiges SNI sowie der Default-Virtual-Host als laufende Pfade geprüft werden.

Transcript-Integrität verleiht keinen Namensanspruch

Unter TLS 1.3 gehört ClientHello zum Transcript, das Finished authentisiert. Ein abgeschlossener Handshake zeigt, dass ein Vermittler den normalen SNI-Wert nicht unbemerkt zwischen den Endpunkten änderte.

Das bestätigt den unveränderten Inhalt der Behauptung. Es bestätigt nicht das Recht des Clients auf diese Behauptung. Der Server weiß, welchen Namen der Client in dieser Verbindung verlangte, aber nicht, ob der Client ihn kontrolliert.

Ohne Client-Zertifikat oder andere Authentisierung kann ein gültiger Handshake den Client anonym lassen. Das Server-Zertifikat wirkt in die Gegenrichtung. Ein korrektes Datenmodell nennt den Wert daher client_requested_server_name, nicht verified_tenant.

Zertifikatwahl und Zertifikatprüfung

SNI hilft dem Server bei der Credential-Auswahl. RFC 9525 verlangt vom Client, akzeptable Referenzidentitäten unabhängig von den im Zertifikat präsentierten Identitäten zu bilden und erst danach zu vergleichen.

Kette, Gültigkeit, Widerruf und Namensabgleich gehören zur Prüfung. Die richtige Auswahl auf der Serverseite beweist keinen dieser Schritte.

OpenSSL trennt die Operationen sichtbar. SSL_set_tlsext_host_name() setzt SNI; der erwartete DNS-Name für die Zertifikatsvalidierung muss zusätzlich gesetzt werden. Nur die erste Funktion aufzurufen kann das gewünschte Zertifikat liefern, ohne den Dienst richtig zu authentisieren.

Ein Zertifikat mit mehreren SANs kann mehrere Namen gültig abdecken. Daraus folgt keine gemeinsame Tenant-Berechtigung.

HTTP bringt eine eigene Authority

Nach TLS übermittelt HTTP/1.1 den Host; HTTP/2 und HTTP/3 verwenden meist :authority. RFC 9110 behandelt diese Information als kritisch für Zielbestimmung und Routing.

Normale Clients leiten SNI und HTTP-Authority häufig aus derselben URI ab. Gleichheit ist dennoch nur ein übliches Ergebnis, keine Protokollbindung. Connection Reuse, Proxies, Tests, Fehler und Angriffe können die Werte trennen.

Der Dienst braucht eine benannte Mismatch-Regel: ablehnen, eine kleine dokumentierte Matrix erlauben oder 421 zurückgeben, wenn die Verbindung für den Origin ungeeignet ist. Das erste SNI darf spätere Requests nicht pauschal autorisieren.

Auch exakte Gleichheit weist keine Client-Identität nach. Zwei konsistente Zielhinweise ersetzen keinen Principal.

Jede TLS-Terminierung eröffnet einen neuen Beleg

Ein terminierender Proxy besitzt einen Downstream-Handshake und startet einen unabhängigen Upstream-Handshake. ClientHello, SNI, Zertifikat, Referenzidentität und Fehlerzustand sind je Verbindung neu.

Upstream-SNI kann fest sein, vom Upstream-Host, von HTTP-Authority oder aus einer kontrollierten Zuordnung stammen. Envoy stellt diese Quellen getrennt bereit und unterscheidet SAN-Prüfung gegen tatsächlich gesendetes SNI von Prüfung gegen Request-Authority.

Bei Passthrough ist die Aussage enger. NGINX ssl_preread kann SNI auslesen und verschlüsselte Bytes weiterleiten, ohne TLS zu terminieren. Das Gerät belegt Hint und Route, nicht Zertifikatvalidierung oder Handshake-Abschluss.

Ein einziges Feld sni verwischt Verbindung, Quelle und Prüfer. Korrelation darf die Beine verbinden, aber ihre Ergebnisse nicht verschmelzen.

ECH macht die Beobachtungsrolle sichtbar

Encrypted Client Hello legt sensible Parameter in ClientHelloInner. ClientHelloOuter enthält normalerweise den öffentlichen Namen des Frontends für Routing und Retry.

Wird ECH angenommen, verarbeitet TLS das authentisierte Inner. Bei Ablehnung kann eine für den öffentlichen Namen authentisierte Verbindung nur Retry-Informationen liefern. RFC 9849 untersagt, sie der Anwendung als erfolgreichen Origin-Kanal zu melden.

Das äußere SNI kann also für Frontend-Routing richtig und als Origin absichtlich unzureichend sein. Telemetrie muss ECH-Status, Beobachterrolle und Namensquelle festhalten, statt ordinary, outer und accepted inner zusammenzufassen.

Zugleich darf sie den inneren Namen nicht breit verteilen. Sonst baut die Monitoring-Schicht das Klartext-Zielregister wieder auf, das ECH vermeiden soll.

Grenzen mit negativen Fällen beweisen

Zuerst wird ohne Client-Credential das SNI des privilegierten Tenants gesendet. Zertifikatwahl und TLS dürfen gelingen; der Principal bleibt anonym und die geschützte Aktion wird verweigert.

Danach folgen fehlendes SNI, unbekannter Name, Default-Fallback, abweichende HTTP-Authority und ein gemeinsames Zertifikat für beide Namen. Am Proxy wird absichtlich ein anderes Upstream-SNI verwendet und werden zwei Prüfresultate verlangt. Passthrough darf keinen TLS-Erfolg behaupten. ECH wird mit Annahme, Ablehnung/Retry und ohne ECH geprüft.

Callbacks in OpenSSL oder GnuTLS zeigen eine Fähigkeit. Erst die Reaktion des ausgeführten Codes auf diese Fälle zeigt die wirksame Grenze.