1.3 Protocol Overview (Synopsis)

Hypertext Transfer Protocol (HTTP), as described in [RFC1945], is both an application layer protocol and a transport. HTTP facilitates communication between clients and servers over multi-tier network architectures that use firewalls and proxies.

Firewalls allow a client and server to communicate directly with one another as long as they use a protocol that has been explicitly allowed by the firewall rules. Firewalls are used to enforce corporate policies and can inspect HTTP payload content. Firewalls typically limit protocol use using two main schemes. The first is based on limiting the destination machines to well-known port addresses. The second scheme inspects the packets flowing over a TCP [RFC793]  connection to validate that the connection is sending packets that are legal for the specified protocol and for the defined firewall policies. Firewalls are generally not detectable.

Proxies typically provide value-added services, such HTML caching, authentication, and auditing services. Using a layered approach, a proxy works in concert with the firewall to provide and enforce protocol specific rules. In the OSI model described in [ISO/IEC 7498-1:1994], proxies route traffic Layer 7, the application layer. The impact of Layer 7 routing is that proxies introduce a tiered architecture, and the proxy requires an extra hop for all client-server traffic. There are many different proxy types and access protocols, especially for HTTP. Firewall architectures typically use a small subset of the available proxy access protocols.

HTTP uses the Transmission Control Protocol (TCP) as its underlying transport. Clients establish TCP connections with servers listening on the well-known TCP port 80. Port 80/TCP is the default port assigned to HTTP by the Internet Assigned Numbers Authority (IANA). See the following figure.

Figure 1: Firewall infrastructure

Depending on the network infrastructure, clients can be blocked from establishing communication directly with servers. Within such infrastructures, firewalls and proxies can provide the only means of communication with a remote server. If a client is unable to communicate directly with a server and instead tries to establish communication with the server via a proxy, it first opens a TCP connection with the proxy using the proxy’s well known port. The client then exchanges information about the target server with the proxy, such as its fully qualified domain name (FQDN), IP address, and port number. Upon successful completion of the proxy negotiation handshake, the proxy opens a TCP connection with the target server on behalf of the client. Target servers typically have no knowledge that they are communicating with a client via a proxy. Ports 80/TCP and 8080/TCP are IANA assigned ports for HTTP. The IANA ports for Secure Sockets Layer (SSL) and SOCKS proxy are 443/TCP and 1080/TCP respectively. The preceding figure and the following figure show typical firewall and proxy configurations.

Figure 2: Firewall and proxy infrastructure

There are two HTTP versions in wide use today, HTTP 1.0 [RFC1945] and HTTP 1.1 [RFC2068]. HTTP encapsulation of Simple Symmetric Transport Protocol (SSTP) is based on HTTP 1.0 because of firewall and proxy traversal dependencies. HTTP 1.0 was chosen because it provides the widest degree of compatibility, which maximizes the chances of establishing an SSTP connection.

HTTP encapsulation of SSTP is designed to specifically encapsulate SSTP. SSTP is documented separately in [MS-GRVSSTP]. SSTP uses TCP as its default transport. A single SSTP connection is layered on a single TCP connection. SSTP allows multiple SSTP sessions to flow between clients and servers. Each session represents an independent communication path between two resources. See the following figure.

Figure 3: Relationship of SSTP connections and sessions

SSTP message data is optionally encrypted by application level protocols using SSTP as a transport. SSTP authentication is provided by SSTP security, a security sub-protocol of SSTP, which is documented separately in [MS-GRVSSTPS].

HTTP encapsulation of SSTP specifies how an SSTP client and server communicate with one another across a network boundary that prevents direct SSTP connectivity on the default 2492/TCP port used by SSTP. These protocols are used when the SSTP protocol fails to establish end-to-end connectivity with a server. This document defines multiple protocols that can be used to navigate through firewalls and proxies. Some protocols, such as Secure Tunnel and SOCKS, negotiate connections with proxies to allow SSTP data to pass through firewalls and proxies. These protocols essentially tunnel though intervening firewalls and proxies. Other protocols, such as the HTTP encapsulation protocols, replace the TCP transport with HTTP, to provide a reliable full-duplex connection-oriented stream, using only the HTTP protocol as a transport. Because proxy implementations vary widely, a suite of HTTP encapsulation protocols are defined to overcome common firewall and proxy restrictions.

These protocols deploy a variety of encapsulation and tunneling techniques to route SSTP across a network boundary that only allows HTTP traffic. These transports are less efficient than SSTP over TCP for a number of reasons, such as the extra proxy hop and overhead required for HTTP encapsulation and connection management.

There are three HTTP encapsulation protocols: LongLived, KeepAlive, and Polling and two tunneling protocols, Secure Tunnel and SOCKS. Each of these protocols is optimized for different proxy architectures. The following table summarizes the various transports supporting SSTP connections.