1.3 Overview

  • Article

This document specifies the Secure Socket Tunneling Protocol (SSTP). SSTP is a mechanism to encapsulate Point-to-Point Protocol (PPP) traffic over an HTTPS protocol, as specified in [RFC1945], [RFC2616], and [RFC2818]. This protocol enables users to access a private network by using HTTPS. The use of HTTPS enables traversal of most firewalls and web proxies.

Many VPN services provide a way for mobile and home users to access the corporate network remotely by using the Point-to-Point Tunneling Protocol (PPTP) and the Layer Two Tunneling Protocol/Internet Protocol security (L2TP/IPsec). However, with the popularization of firewalls and web proxies, many service providers, such as hotels, do not allow the PPTP and L2TP/IPsec traffic. This results in users not receiving ubiquitous connectivity to their corporate networks. For example, generic routing encapsulation (GRE) port blocking by many Internet service providers (ISPs) is a common problem when using PPTP.

This protocol provides an encrypted tunnel (an SSTP tunnel) by means of the SSL/TLS protocol. When a client establishes an SSTP-based VPN connection, it first establishes a TCP connection to the SSTP server over TCP port 443. SSL/TLS handshake occurs over this TCP connection.

After the successful negotiation of SSL/TLS, the client sends an HTTP request with content length encoding and a large content length on the SSL protected connection (see section 3.2.4.1 for more details). The server sends back an HTTP response with status HTTP_STATUS_OK(200). The specific request and response details that are discussed earlier can be found in section 4.1. The HTTPS connection is now established, and the client can send and receive SSTP Control Packets and SSTP Data Packets on this connection. HTTPS connection establishment when a web proxy is present is specified in [SSLPROXY].

SSTP performs the following features:

  • Allowing delineation of PPP frames from the continuous stream of data that is sent by using HTTPS. For more information about PPP, see [RFC1661].

  • Negotiation of parameters between two entities. See section 1.7 for more details.

  • Extensible message format to support new parameters in the future. For more information, see section 2.2.

  • Security operations to prevent a man-in-the-middle attacker from relaying PPP frames inappropriately over SSTP. SSTP uses keying material generated during PPP authentication for crypto binding (sections 3.2.5.2 and 3.3.5.2.3).

SSTP Control Packets contain messages to negotiate parameters and to ensure that there is no untrusted man-in-the-middle. SSTP Data Packets contain PPP frames as payload.

In an SSTP–based VPN, the protocol layer negotiation occurs in the following order:

  • The TCP connection is established to an SSTP server over TCP port 443.

  • SSL/TLS handshake is completed.

  • HTTPS request-response is completed.

  • SSTP negotiation begins.

  • PPP negotiation is initiated, and PPP authentication is completed or bypassed.

  • SSTP negotiation is completed.

  • PPP negotiation is completed.

  • The connection enters a ready state for transportation of any network layer (for example, IP packets).

The following encapsulation operations occur on the client:

  • Application packets are encapsulated over any transport protocol (for example, TCP and UDP).

  • Transport layer packets are encapsulated over a network protocol (for example, IP).

  • Network layer packets are encapsulated over a PPP data-link layer.

  • PPP packets are encapsulated over SSTP.

  • SSTP Packets are encapsulated over SSL/TLS.

  • SSL/TLS records are encapsulated over TCP.

  • TCP packets are encapsulated over IP.

  • IP packets are sent over any data-link layer (such as Ethernet or PPP). For more information about PPP, see [RFC1661].

On the server side, operations to remove the encapsulation occur in reverse order.