Zusammenfassung

  • FEP transportierte ein vollständiges IP-Datagramm im HTTP-Body; ein kooperierender interner Host dekodierte es und speiste es in seinen Protokollstapel ein.
  • Der erfolgreiche HTTP-Durchgang belegte nur den äußeren Transport. Er genehmigte keine inneren Adressen, Ports, Anwendungen, Benutzer, Einspeisung oder Ergebnisse.

Die Regel erkannte die Hülle

Der Text begann mit dem Konflikt zwischen Innovation an den Endpunkten und Kontrolle im Pfad. Eine neue Anwendung konnte auf beiden Hosts funktionieren und trotzdem an der Unternehmensfirewall scheitern, weil ihr Verkehr nicht zu vorhandenen Regeln gehörte. RFC 3093 trieb eine Antwort ins Satirische: Wenn HTTP passieren darf, kann jedes Datagramm wie HTTP aussehen.

Der Ablauf war konkret. Der äußere Host übergab sein TCP/IP-Datagramm an FEP. Die Software legte es in eine HTTP-Nachricht und sendete sie über den üblichen Weg. Innen entnahm ein zweites Programm die Bytes, baute ein IP-Datagramm und fügte es in den geschützten Stack ein, als hätte es keine Firewall gegeben.

Beobachtet wurde dennoch die äußere Sitzung. Das innere Paket behielt eigene Quelle, Ziel, Transportfelder und Bedeutung. Eine Entscheidung über das Fahrzeug ging nicht von selbst auf die Ladung über.

Der interne Helfer erhielt neue Macht

Das Dokument behauptete, das Sicherheitsmodell bleibe gewahrt, weil ein interner Host kooperieren müsse. Dabei setzte es voraus, dass Firewalls äußere und nicht innere Gefahren behandelten. Das ist die Prämisse des Textes, keine Garantie. Ein Prozess, der beliebigen Verkehr auspacken und in den Netzwerkstack schreiben darf, ist selbst ein privilegierter Kontrollpunkt.

Der Firewallbetreiber kontrollierte die äußere Verbindung. Der Hostbetreiber aktivierte FEP und die Einspeisung. Der Benutzer wählte die Anwendung. Die Implementierung interpretierte die Bytes. Keiner dieser einzelnen Akte belegte eine organisatorische Genehmigung der Kombination.

Ein Protokoll „HTTP akzeptiert“ beschrieb daher nicht den verborgenen Fluss. Empfang am Tunnel belegte keine Einspeisung; Einspeisung keinen Socket-Empfang; Socket-Empfang keine Verarbeitung oder äußere Wirkung.

Lesbare Header waren Kopien

Das vollständige Datagramm lag im HTTP-Body. Zusätzlich kopierte FEP TCP- und optionale IP-Felder in lesbare Header: Ports als Dezimaltext, Großschreibung für Dringlichkeit, Lebensdauer als Satz und scheinbare Quellen als Domainnamen.

RFC 3093 erklärte selbst, diese Kopien dienten nur der Lesbarkeit, weil das Datagramm bereits vorhanden war. Ein sichtbares TCP_Dport authentifizierte das tatsächliche Ziel nicht. Beide Darstellungen konnten abweichen. Die Software musste festlegen, welche Rekonstruktion steuerte, Werte prüfen und vor der Einspeisung eine Richtlinie anwenden.

GET-Anfragen und GET-Antworten in beide Richtungen nutzten ebenfalls eine akzeptierte Form. Der Inhalt wurde dadurch nicht zu einer gewöhnlichen Web-Anfrage. HTTP war die vom Vermittler erkannte Oberfläche. Protokollsyntax und Absicht waren verschiedene Prüfgegenstände.

Die Provokation bewahrte ein reales Problem

Datum, absurde Felder und die Verneinung echter Sicherheitsfragen kennzeichnen eine Informational-Provokation, keine sichere Anleitung. Die Absicht der Autoren muss nicht erfunden werden. Der veröffentlichte Mechanismus zeigt bereits, wie eine grobe Freigabe zum allgemeinen Transport wird, wenn ein Endpunkt kapselt.

RFC 2775 behandelte verlorene Transparenz, RFC 2979 Firewallverhalten, RFC 2663, 3027 und 3234 NAT und Middleboxes. SOCKS5 verhandelte ausdrücklich mit einem Gateway und konnte Authentifizierungsmethoden verwenden. Das ist Architekturkontext, kein Beleg für FEP-Betrieb.

Die dauerhafte Aussage ist begrenzt: Eine Regel kann HTTP korrekt erlauben und innere Semantik nicht bewertet haben. Kontrolle verlangt die Identität des Tunnels, dessen Authentifizierung, erlaubte innere Pakete, Einspeiseprivileg, Anwendungsempfang und beobachtete Wirkung als getrennte Nachweise.

Quellen

  1. https://www.rfc-editor.org/info/rfc3093
  2. https://www.rfc-editor.org/rfc/rfc3093.html
  3. https://www.rfc-editor.org/rfc/rfc3093.txt
  4. https://datatracker.ietf.org/doc/rfc3093/
  5. https://www.rfc-editor.org/errata/rfc3093
  6. https://www.rfc-editor.org/rfc/rfc2775.html
  7. https://www.rfc-editor.org/rfc/rfc2979.html
  8. https://www.rfc-editor.org/rfc/rfc3234.html
  9. https://www.rfc-editor.org/rfc/rfc2663.html
  10. https://www.rfc-editor.org/rfc/rfc3027.html
  11. https://www.rfc-editor.org/rfc/rfc1928.html
  12. https://www.rfc-editor.org/rfc/rfc2616.html
  13. https://www.rfc-editor.org/rfc/rfc793.html
  14. https://www.rfc-editor.org/rfc/rfc791.html
  15. https://www.rfc-editor.org/rfc/rfc2119.html