Community hub
0 subscribers7 pages, 0 posts
Recent from talks
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Welcome to the community hub built to collect knowledge and have discussions related to HTTP tunnel.
Nothing was collected or created yet.
HTTP tunnel
View on Wikipediafrom Wikipedia
HTTP tunneling is used to create a network link between two computers in conditions of restricted network connectivity including firewalls, NATs and ACLs, among other restrictions. The tunnel is created by an intermediary called a proxy server which is usually located in a DMZ.
Tunneling can also allow communication using a protocol that normally wouldn’t be supported on the restricted network.
HTTP CONNECT method
[edit]The most common form of HTTP tunneling is the standardized HTTP CONNECT method.[1][2] In this mechanism, the client asks an HTTP proxy server to forward the TCP connection to the desired destination. The server then proceeds to make the connection on behalf of the client. Once the connection has been established by the server, the proxy server continues to proxy the TCP stream to and from the client. Only the initial connection request is HTTP - after that, the server simply proxies the established TCP connection.
This mechanism is how a client behind an HTTP proxy can access websites using SSL or TLS (i.e. HTTPS). Proxy servers may also limit connections by only allowing connections to the default HTTPS port 443, whitelisting hosts, or blocking traffic which doesn't appear to be SSL.
The HTTP CONNECT method can not forward UDP connection.
Example negotiation
[edit]The client connects to the proxy server and requests tunneling by specifying the port and the host computer to which it would like to connect. The port is used to indicate the protocol being requested.[3]
CONNECT streamline.t-mobile.com:22 HTTP/1.1
Proxy-Authorization: Basic encoded-credentials
If the connection was allowed and the proxy has connected to the specified host then the proxy will return a 2XX success response.[3]
HTTP/1.1 200 OK
The client is now being proxied to the remote host. Any data sent to the proxy server is now forwarded, unmodified, to the remote host[3] and the client can communicate using any protocol accepted by the remote host. In the example below, the client is starting SSH communications, as hinted at by the port number in the initial CONNECT request.
SSH-2.0-OpenSSH_4.3\r\n ...
HTTP tunneling without using CONNECT
[edit]A HTTP tunnel can also be implemented using only the usual HTTP methods as POST, GET, PUT and DELETE. This is similar to the approach used in Bidirectional-streams Over Synchronous HTTP (BOSH).
A special HTTP server runs outside the protected network and a client program is run on a computer inside the protected network. Whenever any network traffic is passed from the client, the client repackages the traffic data as a HTTP request and relays the data to the outside server, which extracts and executes the original network request for the client. The response to the request, sent to the server, is then repackaged as an HTTP response and relayed back to the client. Since all traffic is encapsulated inside normal GET and POST requests and responses, this approach works through most proxies and firewalls.[a]
See also
[edit]Notes
[edit]References
[edit]- ^ Fielding, R. (June 1999). "Method Definitions, CONNECT". Hypertext Transfer Protocol -- HTTP/1.1. IETF. p. 56. sec. 9.9. doi:10.17487/RFC2616. RFC 2616. Retrieved Jan 16, 2025.
- ^ Khare, R.; Lawrence, S. (May 2000). Hypertext Transfer Protocol -- HTTP/1.1. IETF. doi:10.17487/RFC2817. RFC 2817. Retrieved Jan 16, 2025.
- ^ a b c Fielding, R.; Reschke, J. (June 2014). "CONNECT". HTTP/1.1 Semantics and Content. IETF. p. 30. sec. 4.3.6. doi:10.17487/RFC7231. RFC 7231. Retrieved Jan 16, 2025.
HTTP tunnel
View on Grokipediafrom Grokipedia
An HTTP tunnel is a networking technique that uses the Hypertext Transfer Protocol (HTTP) to encapsulate and transport data from lower-level protocols, such as TCP, by establishing a bidirectional virtual connection through an intermediary like a proxy server. This is primarily achieved via the CONNECT method in HTTP/1.1, where a client requests the proxy to open a tunnel to a specified destination host and port, allowing transparent forwarding of arbitrary data streams without HTTP semantic processing once established.[1]
The CONNECT method operates by sending a request in the form
Proxy Response (Success):
After the response, raw TCP data (e.g., TLS handshake bytes) flows directly through the tunnel in both directions.[13] For authentication, the client would include
CONNECT <host>:<port> HTTP/1.1, prompting the proxy to connect to the target server; a successful response (status code 2xx, such as 200 OK) signals tunnel activation, after which the proxy relays data blindly in both directions until either endpoint closes the connection.[2] Unlike standard HTTP requests, CONNECT requests contain no body and use an authority-form URI (host and port only, with no default port assumption), and successful responses omit content, Transfer-Encoding, or Content-Length headers to initiate immediate tunneling. This method is hop-by-hop, meaning it applies only between the client and proxy, and is not intended for origin servers.
HTTP tunneling is essential for scenarios requiring secure or restricted access, such as enabling HTTPS connections through corporate firewalls, where the tunnel facilitates end-to-end TLS encryption without proxy inspection of the encrypted payload.[1][2] It supports proxy authentication via headers like Proxy-Authorization and can chain through multiple proxies if needed.[2] However, the method is neither safe nor idempotent, rendering it uncacheable, and proxies are advised to limit tunneling to trusted ports (e.g., 443 for HTTPS) to mitigate risks like unauthorized access or abuse as relays for non-HTTP protocols such as SSH or FTP.[1]
Introduced in early HTTP/1.1 specifications, the CONNECT method was originally outlined in a 1996 work-in-progress document titled "Tunneling TCP based protocols through Web proxy servers" by Ari Luotonen, and later formalized in RFC 2817 for upgrading to TLS within HTTP.[2] Modern extensions, such as the ALPN header in CONNECT requests, allow negotiation of application-layer protocols within the tunnel, enhancing support for diverse uses like HTTP/2 or HTTP/3 multiplexing.[3] Despite its utility, HTTP tunneling raises security considerations, including potential for traffic obfuscation to bypass filters, underscoring the need for robust proxy configurations.[1]
Fundamentals
Definition and Principles
HTTP tunneling is a technique used to encapsulate arbitrary network protocols, such as TCP-based ones, within HTTP messages, thereby disguising non-HTTP traffic as standard web communications to traverse restrictive networks.[4] This encapsulation allows data from lower-level protocols to be transported inside HTTP requests and responses, mimicking legitimate web browsing activity.[5] The core principles of HTTP tunneling involve client-server negotiation to establish the tunnel, data encapsulation within HTTP bodies or headers for non-CONNECT methods, and support for bidirectional communication over a single connection.[6] HTTP tunneling encompasses both opaque relaying via the CONNECT method, where data is forwarded blindly after setup without HTTP framing, and encapsulation techniques that embed protocol data in HTTP message components. During negotiation, the client requests the server to open a pathway, after which the intermediary relays data opaquely without interpreting the encapsulated content. Once established, the tunnel functions as a blind relay, maintaining end-to-end connectivity for the inner protocol while leveraging HTTP's persistent connections for efficiency.[7] HTTP tunneling differs from HTTP proxying, where an intermediary acts as a forwarding agent that receives, interprets, and relays HTTP requests in absolute URI form on behalf of clients. In contrast, tunneling emphasizes protocol encapsulation to create a direct, unmodified pathway for non-HTTP data, with the intermediary ceasing participation in the HTTP communication after setup. A primary benefit of HTTP tunneling is its ability to bypass firewalls and proxies that allow outbound HTTP traffic on ports 80 and 443 but block other protocols or ports, facilitating access in controlled environments like corporate networks.[5] This approach enables secure or restricted applications to operate without altering network policies.Historical Development
The concept of HTTP tunneling emerged in the mid-1990s alongside the development of early HTTP specifications, driven by the need for intermediaries like proxies to facilitate communication in distributed networks. HTTP/1.0, formalized in RFC 1945 in May 1996, introduced basic proxy support, defining proxies as intermediaries that forward requests and responses while allowing for tunneling as a blind relay mechanism to pass data through firewalls or other barriers without alteration.[8] This laid the groundwork for encapsulating non-HTTP traffic within HTTP, though without a dedicated method for dynamic tunnel establishment.[9] The technique evolved significantly with HTTP/1.1, published as RFC 2616 in June 1999, which formalized the CONNECT method to enable proxies to switch to a raw TCP tunnel for secure or arbitrary protocol transport.[10] This method, originally outlined in Ari Luotonen's 1996 Internet Draft "Tunneling TCP based protocols through Web proxy servers," allowed clients to request a bidirectional data relay to a target host and port, commonly used for SSL-encrypted connections.[11] The rise of HTTP tunneling in the late 1990s was closely tied to increasing firewall deployments, which restricted direct access to non-HTTP ports, prompting tools like httptunnel—first released around 1998—to encapsulate protocols such as SSH within HTTP requests for bypass purposes. By the early 2000s, HTTP tunneling saw broader integration into browsers and proxy servers, enabling seamless support for HTTPS traffic through CONNECT-based tunnels to handle TLS-encrypted sessions without exposing sensitive data to intermediaries.[4] Adaptations for TLS over HTTP tunnels became standard during this period, aligning with the growing adoption of secure web communications amid rising network restrictions. Post-2010 milestones included WebSockets (RFC 6455, December 2011), which provided a persistent, bidirectional alternative to full tunneling for real-time applications, and HTTP/2 (RFC 7540, May 2015), which enhanced tunneling via multiplexing to allow multiple streams over a single connection, improving efficiency for proxy-relayed traffic.[12] As of 2025, HTTP tunneling remains relevant in cloud environments for secure exposure of internal services without public IPs. However, its use has declined for some firewall bypass scenarios due to advanced deep packet inspection (DPI) techniques that detect and block anomalous HTTP patterns, favoring more obfuscated alternatives like WebSockets.Tunneling Methods
HTTP CONNECT Method
The HTTP CONNECT method, defined in HTTP/1.1, enables a client to request that a proxy server establish a bidirectional TCP connection to a specified target host and port, effectively creating a tunnel for arbitrary data relay.[13] This method is particularly useful for encapsulating protocols like HTTPS through proxies, where the proxy acts as a blind forwarder after successful establishment, without interpreting the tunneled content.[14] Specified in RFC 7231 (June 2014), CONNECT uses an authority-form request-target, focusing solely on the destination authority rather than a full URI path.[13] The process begins with the client sending a CONNECT request to the proxy, formatted asCONNECT <host>:<port> HTTP/1.1, followed by required headers and a blank line.[15] The proxy then attempts to open the TCP connection to the target; upon success, it responds with a 2xx status code (typically 200 OK), indicating the tunnel is established, and immediately begins relaying raw bytes bidirectionally between the client and target without applying HTTP framing, Transfer-Encoding, or Content-Length to the tunneled data.[16] If the connection fails or is unauthorized, the proxy returns a 4xx or 5xx error response with a message body explaining the issue, and no tunnel is created.[13] Once active, the tunnel persists until either endpoint closes the connection, with the proxy forwarding all subsequent data transparently.[13]
Relevant HTTP headers in a CONNECT request include the mandatory Host header, which must match the authority in the request-target to specify the tunnel destination.[17] Optional headers like User-Agent can provide client identification for negotiation or logging purposes, while Proxy-Authorization supports authentication schemes (e.g., Basic or Digest) if the proxy requires credentials, as triggered by a prior 407 Proxy Authentication Required response.[18] The Connection header may also appear to control options like "close" for the proxy connection.[19] Responses to successful CONNECT requests exclude Content-Length or Transfer-Encoding headers, as no entity body is present.[16]
CONNECT is compatible with both plain HTTP connections to the proxy and HTTPS-secured proxy connections, allowing secure request transmission before tunneling.[13] In HTTP/1.1, it operates over a single persistent connection, limiting concurrent tunnels without additional mechanisms.[20] HTTP/2 extends support for CONNECT (per RFC 7540, May 2015), enabling multiplexing of multiple proxy requests over one connection while establishing the tunnel on a dedicated stream, though the tunnel itself remains non-multiplexed.[21]
A typical CONNECT negotiation trace, assuming no authentication, appears as follows (wire format example adapted from RFC 7231):
Client Request:
CONNECT www.[example.com](/page/Example.com):443 HTTP/1.1
Host: www.[example.com](/page/Example.com):443
User-Agent: ExampleClient/1.0
CONNECT www.[example.com](/page/Example.com):443 HTTP/1.1
Host: www.[example.com](/page/Example.com):443
User-Agent: ExampleClient/1.0
HTTP/1.1 [200](/page/200) Connection Established
Date: Mon, 10 Nov 2025 12:00:00 GMT
HTTP/1.1 [200](/page/200) Connection Established
Date: Mon, 10 Nov 2025 12:00:00 GMT
Proxy-Authorization: Basic <base64-credentials> in the request if previously challenged.[18]
Non-CONNECT Methods
Non-CONNECT methods for HTTP tunneling leverage standard HTTP request and response mechanisms, such as the POST method, to encapsulate and transport arbitrary data through proxies or firewalls that block the CONNECT method. In these approaches, the client encodes binary or non-HTTP protocol data into the body of HTTP POST requests, often using Base64 to ensure compatibility with text-based HTTP transmission, while the server-side handler decodes the payload, forwards it to the intended destination, and encodes the reply in the HTTP response body.[22][23] State management across multiple requests is typically maintained using session identifiers in cookies or URL parameters, allowing the tunnel to simulate persistent connections despite the stateless nature of HTTP.[22] Chunked transfer encoding, defined in HTTP/1.1, enables streaming of indefinite data lengths without a fixed Content-Length header, facilitating more efficient simulation of bidirectional flows in non-CONNECT tunnels.[24] This technique divides the tunneled data into chunks, each preceded by its hexadecimal size and terminated by CRLF, with the stream ending via a zero-length chunk; it is particularly useful for real-time protocols where content size is unknown upfront.[24] Tools like chunkyTuna exploit this by embedding TCP stream data within chunked HTTP responses from a webshell, allowing interactive command execution or port forwarding without requiring persistent connections.[25] In bidirectional setups, the client sends chunked POST requests for outbound data, while the server responds with chunked bodies containing inbound replies, though this requires custom server-side processing to reassemble streams.[26] Header-based tunneling embeds small amounts of data directly into custom HTTP headers or URL query parameters, avoiding the body altogether for minimal payloads like control signals or short messages. For instance, proprietary headers such as X-Tunnel-Data can carry Base64-encoded snippets, parsed by the server to route or acknowledge tunneled traffic.[27] However, this method is inherently limited by HTTP header size constraints, typically around 8 KB per request, making it unsuitable for bulk data transfer. Implementations of these non-CONNECT methods include tools like HTTPTunnel, which creates bidirectional virtual data paths over pure GET and POST requests, encoding traffic to traverse restrictive proxies without invoking CONNECT.[22] Custom scripts, often written in languages like Python or Go, further demonstrate these techniques by Base64-encoding non-HTTP protocols (e.g., SSH or TCP) into POST bodies for server-side decoding and forwarding.[28] GOST, a versatile proxy tool, also employs GET for control messages and POST for data payloads in its HTTP tunnel mode, supporting both encrypted and plaintext variants to mimic legitimate web traffic.[29] These methods exhibit a unidirectional bias, as HTTP's request-response model favors client-to-server data flow, requiring polling or long-lived requests for reverse directionality, which increases latency.[22] They incur higher overhead from repeated encoding/decoding cycles and multiple round-trip requests compared to direct tunnels.[30] Additionally, their reliance on visible request bodies or headers makes them vulnerable to content inspection by deep packet inspection tools, which can detect anomalous patterns like excessive Base64 usage or irregular chunking.[23]Applications and Examples
Proxy and Firewall Bypass
HTTP tunneling enables the circumvention of network proxies and firewalls by encapsulating restricted protocols within HTTP traffic, which is typically whitelisted on ports 80 and 443 due to its essential role in web browsing. This mechanism allows protocols like FTP or Telnet, often blocked on their standard ports, to be routed through these open channels using methods such as the HTTP CONNECT request, which establishes a transparent TCP tunnel without proxy interpretation of the payload.[6][31][32] In proxy integrations, forward proxies like Squid support outbound tunneling via CONNECT, enabling clients behind a restrictive network to connect to external destinations by forwarding encapsulated traffic, while reverse proxies can terminate incoming tunnels for internal services. This setup is common in corporate environments, where employees use HTTP tunneling to access blocked external resources through the company's proxy infrastructure without violating port restrictions.[31][33] Practical examples include accessing censored websites in restricted networks during the Arab Spring uprisings, where tools like Psiphon employing HTTP proxying helped users evade government blocks on social media and news sites, including in Syria.[34][35] Similarly, in corporate intranets, HTTP tunneling routes internal tools or external services through approved HTTP paths, maintaining productivity while adhering to security policies. A notable case study is the early version of Psiphon, released in 2006 by the Citizen Lab, which utilized CGI proxying over HTTP to create encrypted tunnels for bypassing firewalls in censored regions. Psiphon distributed proxy lists via social networks, allowing users to route traffic through volunteer-hosted servers, successfully evading IP, DNS, and keyword filters in tests across locations like China and Vietnam. As of 2025, Psiphon continues to be used as a circumvention tool in regions with internet restrictions, evolving into a full VPN service.[36][37] Performance in these scenarios involves added latency from encapsulation overhead, as HTTP headers and proxy processing introduce delays—lab evaluations of similar tools showed approximately 83-85% slower response times compared to direct connections. Scalability can be challenged in high-traffic environments, where frequent tunnel establishments increase load on proxies, though optimized implementations like Squid mitigate this through caching and efficient forwarding.[36][31]Secure Protocol Encapsulation
HTTP tunneling enables the encapsulation of secure protocols such as SSH and VPN traffic within HTTP requests and responses, allowing transmission over networks that restrict non-HTTP traffic. This process involves wrapping the inner protocol's packets—typically encrypted by the secure protocol itself—into HTTP payloads, often using methods like POST requests for data transfer or the CONNECT method for establishing persistent tunnels. Tools like httptunnel facilitate this by creating a bidirectional virtual data path where arbitrary TCP/IP connections, including SSH, are tunneled through HTTP requests that can traverse HTTP proxies.[28] Similarly, stunnel can wrap SSH connections in TLS before further encapsulation in HTTP, adding an additional layer of encryption compatible with HTTP/HTTPS proxies.[38] For SSH encapsulation, the protocol's packets are mapped into HTTP requests by segmenting the TCP stream into chunks that fit within HTTP bodies or headers, with the tunnel server reassembling them for delivery to the SSH endpoint. This supports various port forwarding modes: local forwarding (-L) redirects a local port to a remote host via the tunnel, remote forwarding (-R) exposes a remote port to the local machine, and dynamic forwarding (-D) creates a SOCKS proxy for flexible application routing. In restricted environments, this mapping allows SSH sessions to mimic legitimate web traffic, evading deep packet inspection that blocks direct SSH on port 22.[5] VPN traffic can also be encapsulated over HTTP, as seen in OpenVPN's support for HTTP proxies, where the VPN protocol requires TCP as the carrier to issue CONNECT requests to the proxy, encapsulating the entire OpenVPN stream—including authentication and data packets—within the proxied connection.[39] Cisco AnyConnect similarly leverages HTTP proxies for initial VPN establishment, wrapping its TLS-based tunnel (which can carry IPsec/IKEv2 payloads) in HTTPS to connect through corporate proxies before shifting to the full secure session.[40] These methods ensure the inner VPN encryption remains intact while the outer HTTP layer provides camouflage. Modern tools like Tunnelmole, as of 2025, extend HTTP tunneling for secure local development and testing environments, encapsulating protocols over HTTP for remote access in restricted networks.[41] HTTP tunnels maintain bidirectional flow by alternating between client-initiated requests carrying outbound data and server responses with inbound data, often using persistent connections or polling mechanisms to simulate full-duplex communication over HTTP's request-response model. Error handling for connection drops typically involves automatic reconnection attempts by the tunnel client, with timeouts and retries configured to detect proxy interruptions or network failures without disrupting the inner secure protocol session.[28] A practical example is establishing an SSH connection over an HTTP CONNECT proxy using netcat (nc) as a ProxyCommand:ssh -D 8080 -o ProxyCommand="nc -X connect -x proxy.example.com:8080 %h %p" user@remotehost. This command directs SSH to use netcat for proxying via HTTP CONNECT to the target host and port, creating a dynamic SOCKS proxy on local port 8080 for tunneled applications.
In restricted networks, this encapsulation combines the inner protocol's robust encryption—such as SSH's AES or VPN's IPsec—for data confidentiality with HTTP's ubiquity for camouflage, enabling secure access where direct connections are blocked while minimizing detection by traffic analyzers that permit standard web protocols.[42]