HTTP-Tunneling dient dazu, eine Netzwerkverbindung zwischen zwei Computern auch bei eingeschränkter Netzwerkverbindung herzustellen, beispielsweise durch Firewalls , NATs und ACLs . Der Tunnel wird von einem Vermittler, einem sogenannten Proxy-Server, erstellt , der sich üblicherweise in einer DMZ befindet .

Durch Tunneling kann auch die Kommunikation über ein Protokoll ermöglicht werden , das im eingeschränkten Netzwerk normalerweise nicht unterstützt würde.

HTTP-CONNECT-Methode

Die gebräuchlichste Form des HTTP-Tunnelings ist die standardisierte HTTP-CONNECT -Methode. [ 1 ] [ 2 ] Dabei fordert der Client einen HTTP-Proxy-Server auf, die TCP -Verbindung an das gewünschte Ziel weiterzuleiten. Der Server stellt die Verbindung dann im Namen des Clients her. Sobald die Verbindung vom Server hergestellt ist, leitet der Proxy-Server den TCP-Datenstrom weiterhin an den Client und von diesem weiter. Nur die anfängliche Verbindungsanfrage erfolgt über HTTP – danach dient der Server lediglich als Proxy für die bestehende TCP-Verbindung.

Dieser Mechanismus ermöglicht es einem Client hinter einem HTTP-Proxy, über SSL oder TLS (HTTPS) auf Websites zuzugreifen . Proxy-Server können Verbindungen auch einschränken, indem sie nur Verbindungen über den Standard-HTTPS-Port 443 zulassen, Hosts auf eine Whitelist setzen oder Datenverkehr blockieren, der nicht als SSL-Verbindung erkennbar ist.

Die HTTP-CONNECT-Methode kann keine UDP -Verbindungen weiterleiten, es sei denn, die MASQUE-Methode wird für QUIC verwendet. [ 3 ]

Beispiel einer Verhandlung

Der Client verbindet sich mit dem Proxy-Server und fordert einen Tunnel an, indem er den Port und den Host-Computer angibt, zu dem er eine Verbindung herstellen möchte. Der Port dient zur Angabe des angeforderten Protokolls. [ 4 ]

CONNECT streamline.t-mobile.com:22 HTTP / 1.1 Proxy-Authorization : Basic encoded-credentials

Wenn die Verbindung zugelassen wurde und der Proxy eine Verbindung zum angegebenen Host hergestellt hat, gibt der Proxy eine 2XX-Erfolgsantwort zurück. [ 4 ]

HTTP / 1.1 200 OK

Der Client wird nun über einen Proxy an den Remote-Host weitergeleitet. Alle an den Proxy-Server gesendeten Daten werden unverändert an den Remote-Host weitergeleitet [ 4 ] , und der Client kann über jedes vom Remote-Host akzeptierte Protokoll kommunizieren. Im folgenden Beispiel startet der Client eine SSH-Kommunikation, wie die Portnummer in der ersten CONNECT-Anfrage andeutet.

SSH-2.0-OpenSSH_4.3\r\n ... 

HTTP-Tunneling ohne CONNECT

Ein HTTP-Tunnel kann auch ausschließlich mit den üblichen HTTP-Methoden POST, GET, PUT und DELETE implementiert werden. Dies ähnelt dem Ansatz, der bei Bidirectional-streams Over Synchronous HTTP ( BOSH ) verwendet wird.

Ein spezieller HTTP-Server läuft außerhalb des geschützten Netzwerks, während ein Clientprogramm auf einem Rechner innerhalb des geschützten Netzwerks ausgeführt wird. Sobald Netzwerkverkehr vom Client gesendet wird, verpackt dieser die Daten in eine HTTP-Anfrage und leitet sie an den externen Server weiter. Dieser extrahiert und führt die ursprüngliche Netzwerkanfrage für den Client aus. Die Antwort auf die Anfrage wird anschließend wieder in eine HTTP-Antwort verpackt und an den Client zurückgesendet. Da der gesamte Datenverkehr in normale GET- und POST-Anfragen und -Antworten eingebettet ist, funktioniert dieses Verfahren auch durch die meisten Proxys und Firewalls hindurch. [ a ]

Siehe auch

Anmerkungen

Referenzen

  1. ^ Fielding, R. (Juni 1999). „Methodendefinitionen, CONNECT“ . Hypertext Transfer Protocol – HTTP/1.1 . IETF . S. 56, Abschnitt 9.9. doi : 10.17487/RFC2616 . RFC 2616. Abgerufen am 16. Januar 2025 .
  2. ^ Khare, R.; Lawrence, S. (Mai 2000). Hypertext Transfer Protocol -- HTTP/1.1 . IETF . doi : 10.17487/RFC2817 . RFC 2817 . Abgerufen am 16. Januar 2025 .
  3. ^ „Multiplexed Application Substrate over QUIC Encryption (masque)“ . datatracker.ietf.org . Abgerufen am 30.12.2025 .
  4. ^ a b c Fielding, R.; Reschke, J. (Juni 2014). "CONNECT" . HTTP/1.1 Semantics and Content . IETF . S. 30. Abschn. 4.3.6. doi : 10.17487/RFC7231 . RFC 7231. Abgerufen am 16. Januar 2025 .