Zusammenfassung

  • Das Serverzertifikat liefert präsentierte Kennungen; die zulässigen Referenzkennungen muss der Client davon unabhängig festlegen.
  • DNS-Auflösung, Lastverteilung und SVCB- oder HTTPS-Records dürfen den Verbindungsweg ändern, ohne automatisch die Identität des ursprünglichen Dienstes umzubenennen.
  • Eine Namensübereinstimmung ersetzt weder PKIX-Pfadprüfung, Gültigkeit und Widerruf noch die fachliche Autorisierung einer Transaktion.

Die Prüfvorgabe kommt nicht vom Prüfling

RFC 9525 trennt die presented identifiers im Endzertifikat des Servers von den reference identifiers des Clients. Die erste Menge sagt, für welche Namen das Zertifikat ausgestellt wurde. Die zweite hält fest, welchen Dienst der Client nach dem Verständnis seiner Anwendung erreichen wollte.

Entnähme der Client seine Akzeptanzliste erst dem vorgelegten Zertifikat, dürfte der Server Anspruch und Maßstab zugleich formulieren. Der Vergleich könnte formal gelingen, hätte aber keine unabhängige Aussage mehr. Deshalb muss die Anwendung ihre zulässigen Referenzen aufbauen, bevor sie die Zertifikatsnamen betrachtet.

Ein erfolgreicher Vergleich validiert genau die getroffene Referenzidentität. Er errät keine Nutzerabsicht, heilt keine manipulierte Eingabe und entscheidet auch nicht, welche Organisation einen anschließenden Geschäftsprozess kontrollieren darf.

Der Ursprungsname braucht Herkunft

Der Quelldomainname entsteht typischerweise aus einer URL, einer Konfiguration, einer direkten Eingabe oder einem anderen von der Anwendung verstandenen Verweis. Je nach Protokoll kann auch der Diensttyp Bestandteil der Referenz sein. TLS selbst kennt diese Vorgeschichte nicht; ihre sichere Erzeugung gehört der Anwendung.

Damit beginnt die Identitätskette vor dem Handshake. Ein Phishing-Link kann auf eine Angreiferdomain zeigen, die für ihren eigenen Namen ein vollkommen gültiges Zertifikat besitzt. Kryptografisch ist die Verbindung korrekt, doch der Zweck wurde bereits in der Eingabe ausgetauscht.

Für sensible Clients reicht es daher nicht, den späteren Zertifikatsnamen zu protokollieren. Sie müssen auch die Quelle der Referenz, erlaubte Umschreibungen und den Kontext festhalten, in dem die Eingabe als vertrauenswürdig galt.

Namensauflösung verleiht keine neue Identität

DNS kann CNAMEs, operative Zwischenziele und schließlich einen anderen Host liefern. Solche Namen sind Wegweiser. Sie werden nicht allein deshalb zu Referenzkennungen, weil sie auf dem Auflösungsweg auftauchen. Eine Anwendung darf sie nur über eine eigene, authentisierte Regel aufwerten.

Die Grenze ist praktisch bedeutsam: Infrastruktur darf Maschine, Region oder Anbieter wechseln, ohne damit automatisch die vom Nutzer adressierte Herkunft zu besitzen. Wer alle Auflösungsziele in die Zertifikatsprüfung übernimmt, verschiebt unbemerkt Entscheidungsmacht vom Ursprung zur Lieferkette.

SVCB lenkt den Verkehr, nicht die Absicht

SVCB- und HTTPS-Resource-Records können alternative Endpunkte, Transportparameter und einen TargetName bekanntgeben. RFC 9460 hält dennoch am ursprünglichen Dienstnamen fest. Das Zertifikat wird für den Ursprung geprüft; SNI und anwendungsseitige Autorität werden nicht bloß auf das technische Ziel umgeschrieben.

So lässt sich Verkehr an eine neue Edge oder einen externen Betreiber verlagern, ohne diesem Betreiber die Auswahl aller akzeptablen Identitäten zu übertragen. Discovery beantwortet, wo Pakete landen. Authentisierung beantwortet, ob dort der vorher benannte Dienst spricht.

Kennungstypen setzen unterschiedliche Grenzen

DNS-ID, IP-ID, SRV-ID und URI-ID sind keine beliebig austauschbaren Zeichenketten. Manche tragen nur einen Host, andere binden zusätzlich einen Diensttyp. Die Anwendung bestimmt vorab, welche Typen sie akzeptiert und in welcher Reihenfolge sie diese auswertet.

Auch der Platzhalter für DNS-ID bleibt eng: genau ein Wildcard-Zeichen als vollständiges linkes Label, das nur ein Label überbrückt. Großzügigere Interpretation macht aus einer Ausstellungserleichterung eine weitreichende Identitätsdelegation.

Zertifikate mit zahlreichen Namen sparen zwar Betriebsschritte, koppeln aber zuvor getrennte Angriffsflächen. Ein verlorener Schlüssel oder eine fehlerhafte Ausstellung berührt dann jeden Namen im gemeinsamen Zertifikat.

Ein Namensfund ist nur eine Prüfung

Die Kennungsübereinstimmung ist nicht die gesamte Zertifikatsvalidierung. Der Client muss weiterhin einen vertrauenswürdigen Zertifizierungspfad aufbauen, Zeitfenster und Einschränkungen prüfen sowie passende Widerrufssignale berücksichtigen. Anschließend entscheidet die Anwendung getrennt, ob die bestätigte Identität die verlangte Handlung ausführen darf.

Das verhindert den Fehlschluss, ein passender Name mache jede Transaktion legitim. Ein Server kann echt sein, während der Auftrag aus einer getäuschten Oberfläche stammt oder das Konto für ihn nicht autorisiert ist.

Bei Abweichung schließen, beim Treffer die Herkunft bewahren

Findet ein automatischer Client keine zulässige Übereinstimmung, sollte er abbrechen oder einer ausdrücklich beschlossenen Richtlinie folgen. Er darf nicht während des Fehlers einen ähnlichen Namen auswählen oder die Akzeptanzmenge erweitern. Eine Nutzer-Ausnahme verlagert eine technisch kaum sichtbare Identitätsfrage an die falsche Stelle.

Bei Erfolg sollten Telemetrie und Audit den validierten Referenzwert, seinen Typ, seine Quelle sowie den Discovery-Pfad zum Endpunkt bewahren. Wer nur das Zertifikat speichert, kann später nicht unterscheiden, ob ein richtiger Dienst oder lediglich ein richtig beurkundeter fremder Dienst erreicht wurde.

Quellen