Summary

  • Die HTTP-Option in RFC 10011 ist für einen vorgeschalteten TLS-Terminator bestimmt. Sie erlaubt keine offen erreichbare RESTCONF-Verbindung im Klartext.
  • Laut RFC erweitert sich die Sicherheitsgrenze bis zum Terminator. Externe Adresse, Proxy-Anzahl und Zertifikat-Header beschreiben den Sollaufbau, belegen aber keinen konkreten Request-Pfad.
  • Daniel Kade schlägt einen Terminierungsgrenzen-Beleg vor, der äußere Authentisierung, Header-Regeln, Backend-Zugang, RESTCONF-Namen und NACM-Entscheidung verbindet.

Wenn der geschützte Kanal früher endet als der Auftrag

Ein Load Balancer prüft das Client-Zertifikat und beendet TLS. Danach sendet er HTTP an den RESTCONF-Server. Dieser liest einen Header, leitet daraus einen Benutzernamen ab und wendet NACM an. Beide Komponenten können korrekt arbeiten, während die Verbindung zwischen ihren Aussagen unbewiesen bleibt.

Hat der Terminator den Header selbst geschrieben? Wurde ein gleichnamiger Wert des Clients zuvor entfernt? Konnte ein anderer Host das Backend direkt erreichen? Gehört der übermittelte Wert zur aktuellen TLS-Sitzung? Diese Fragen liegen weder vollständig im TLS-Handshake noch in der Zugriffstabelle.

RFC 10011 definiert YANG-Modelle für RESTCONF-Clients und -Server, einschließlich Call Home. HTTPS bleibt der vorgeschriebene Transport. Eine HTTP-Lauschoption existiert nur für die externe Terminierung. Die Sicherheitsbetrachtung zieht daraus ausdrücklich die Konsequenz, dass sich die Grenze bis zum TLS-Terminator erstreckt.

Die Verschlüsselung darf also an der Kante enden. Die Nachweiskette darf es nicht.

Kein Freibrief für Klartext

RFC 8040 untersagt RESTCONF über HTTP ohne TLS. RFC 10011 schwächt diese Regel nicht, sondern modelliert einen geteilten Stack: außen HTTPS, innen eine Verbindung nach bereits erfolgter Terminierung.

http-listen als allgemeine Erlaubnis zu lesen, wäre ebenso falsch wie jeden internen HTTP-Hop pauschal als unzulässig zu bezeichnen. Entscheidend ist, ob der externe Terminator und der nachgelagerte Pfad eine kontrollierte Sicherheitsgrenze bilden.

Zentrale Terminierung kann Zertifikatswechsel, Skalierung und Richtlinien vereinfachen. Sie verteilt jedoch Zuständigkeit. Die Plattform prüft den Peer, das Netz beschränkt die Backend-Erreichbarkeit, das Identitätssystem bildet Zertifikate auf Namen ab, und RESTCONF/NACM entscheidet über Operationen.

Konfiguration zeigt Absicht

Im Servermodell beschreibt external-endpoint die externe Adresse und den Port, trusted-proxy-count sowie client-cert-var. Letzteres benennt den HTTP-Header, mit dem ein externer Terminator Client-Zertifikate weiterreichen kann; als Beispiel dient X-Client-Cert. Das Feld ist optional, weil RESTCONF auch andere Authentisierungswege kennt.

Die Knoten machen die Architektur maschinenlesbar. Sie machen sie nicht selbstbeweisend. Eine konfigurierte Adresse belegt nicht, dass der Request dort eintraf. Eine erwartete Proxy-Zahl misst keine aktuellen Hops. Ein Headername zeigt weder, wer ihn schreiben konnte, noch ob sein Inhalt aus dem validierten Zertifikat dieser Sitzung stammt.

Das ist keine Schwäche des Modells. YANG beschreibt den Sollzustand und schafft eine gemeinsame Sprache. Prozessidentität, geladene Revision, Laufzeitbeobachtung und Negativtest liefern eine andere Evidenzklasse. Governance scheitert, wenn aus der ersten die zweite abgeleitet wird.

Der Benutzername hat eine Herkunft

Bei interner TLS-Terminierung kann der Server den authentisierten Peer direkt an den Request-Kanal binden. Bei externer Terminierung wird die Identität übersetzt: volles Zertifikat, Subject, bestätigter Name oder begrenztes Attribut. Jede Variante braucht Regeln für Normalisierung, Mehrdeutigkeit, fehlende Werte und Kollisionen.

Ebenso wichtig ist die Header-Hygiene. Eingehende Identitätsheader müssen nach einer festgelegten Regel entfernt oder überschrieben werden. Das Backend darf sie nur von autorisierten Quellen akzeptieren. Wiederholungen und Failover brauchen eine Rückverbindung zur ursprünglichen TLS-Sitzung.

NACM aus RFC 8341 entscheidet auf Grundlage eines authentisierten Benutzernamens. Ist dieser falsch abgeleitet, kann NACM die richtige Regel für die falsche Person anwenden. Ein korrektes Ergebnis des Autorisierers beweist nicht die vorgelagerte Identitätskette.

Bei Call Home kehrt RFC 8071 nur die TCP-Initiierung um. TLS- und RESTCONF-Rollen bleiben bestehen. Dass ein Gerät die Verbindung eröffnet hat, ersetzt keine Zertifikatsprüfung und darf nicht als Identitätsnachweis missverstanden werden.

Das Backend ist kein leerer Zwischenraum

Nach dem Terminator durchläuft der Request einen realen Pfad. Isoliertes Segment, lokaler Socket, Service-Identität oder eine weitere geschützte Schicht können angemessen sein. RFC 10011 schreibt kein einzelnes Muster vor. Seine Grenzaussage verlangt aber, den gewählten Schutz in die Assurance aufzunehmen.

„Intern“ sagt nicht, wer den Port erreichen kann, welcher Proxy Header erzeugen darf oder wie ein Ausfall den Weg verändert. Formale Kontrolle über ein Zertifikat ist keine praktische Kontrolle über jede Komponente, die dem Managementdienst eine Identität behaupten kann.

RFC 9641, 9642 und 9645 standardisieren Truststore, Keystore und TLS-Gruppierungen. Sie schärfen den konfigurierten Zustand. Sie attestieren nicht, welche Version der laufende Prozess lud oder welcher interne Request aus welcher äußeren Sitzung entstand.

Ein Beleg für die Terminierungsgrenze

Ich schlage für jeden extern terminierten RESTCONF-Endpunkt einen Terminierungsgrenzen-Beleg vor. Dies ist Daniel Kades redaktionelle Governance-Empfehlung, keine zusätzliche Vorgabe aus RFC 10011.

Der Beleg identifiziert zunächst Endpunkt, Rolle, Konfigurationsrevision, erwartete Proxy-Kette und Eigentümer. Er referenziert Zertifikat, Vertrauensrichtlinie, Authentisierungsmethode und Rotationsstatus, ohne Schlüssel, Token oder vollständige Konfigurationen zu speichern.

Danach hält er den Identitätsvertrag fest: zulässige Header, Abbildungsregel, Entfernung fremder Werte, verpflichtendes Überschreiben und Fehlerverhalten bei Lücke oder Konflikt. Das außen beobachtete Zertifikat und das innen gelieferte Attribut bleiben getrennte Felder.

Ein dritter Teil beschreibt den Backend-Schutz: erlaubte Quellen, Isolation, erwartete Hop-Zahl und Ergebnis eines Bypass-Tests. Richtlinienkennung und begrenzter Hash genügen; private Topologie und Firewall-Dumps gehören nicht hinein.

Schließlich verbindet eine Trace-ID TLS-Ereignis, internen HTTP-Request, abgeleiteten RESTCONF-Namen und NACM-Entscheidung. Zeit, Software- und Policy-Version, Prüfergebnis und begrenzte Log-Hashes machen die Kette überprüfbar, ohne den Managementinhalt zu kopieren.

Der Beleg verfällt bei Zertifikats-, Truststore-, Proxy-, Routing-, Header- oder NACM-Änderungen. Er ist eine zeitgebundene Aussage über laufende Kontrolle.

Nahtstellen prüfen

Ein aussagekräftiger Test sendet den geschützten Header von einer nicht vertrauenswürdigen Quelle und erwartet Entfernung oder Ablehnung. Er nutzt ein Zertifikat mit geringen Rechten und prüft den Backend-Namen. Er versucht den direkten Portzugang. Er lässt die äußere Authentisierung scheitern und bestätigt, dass kein korrelierter Backend-Request entstand.

Auch Standby-Balancer, Wartungswege und alte Listener gehören in den Umfang. Ein erfolgreicher Hauptpfad widerlegt keine vergessene Umgehung.

Berichte sollten die Schichten benennen: „äußeres TLS validiert“, „Identität von zugelassenem Terminator übernommen“, „Backend-Bypass abgewiesen“, „NACM-Entscheidung korreliert“. Erst mit bekanntem Umfang und frischer Evidenz darf daraus „RESTCONF geschützt“ werden.

RFC 10011 zeigt damit einen nüchternen Grundsatz: Der Ort der Entschlüsselung kann delegiert werden. Die Verantwortung für die daraus entstehende Identität nicht.

Quellen

  1. Lu Heng — Datensouveränität: technische und praktische Realität
  2. Lu Heng — Warum BTW Media existiert
  3. Lu Heng — Vorrang des laufenden Codes
  4. IANA — YANG Parameters
  5. RFC 10011 — YANG-Modell für RESTCONF-Clients und -Server
  6. RFC 8040 — RESTCONF Protocol
  7. RFC 8071 — NETCONF und RESTCONF Call Home
  8. RFC 8341 — Network Configuration Access Control Model
  9. RFC 8342 — Network Management Datastore Architecture
  10. RFC 8446 — TLS 1.3
  11. RFC 9000 — QUIC
  12. RFC 9110 — HTTP Semantics
  13. RFC 9641 — YANG-Modell für einen Truststore
  14. RFC 9642 — YANG-Modell für einen Keystore
  15. RFC 9645 — YANG-Gruppierungen für TLS
  16. RFC 10009 — YANG-Gruppierungen für HTTP