Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
The Secure Tunnel Proxy Protocol, also known as the SSL Tunnel Protocol [SSLPROXY], is an internet draft standard described in Secure Tunnel Proxy Protocol [TCPPROXY]. It was originally designed to allow SSL traffic through an HTTP proxy and uses the well-known port 443/TCP. SSL requires a tunnel because traffic is encrypted. Without a tunnel the HTTP proxy would need the client’s and server’s X.509 keys [RFC2459] to decrypt and parse the SSL stream, which would weaken the security of the system. The Secure Tunnel Proxy Protocol solves this problem by using the HTTP Connect Method [RFC1945] for proxy negotiation. The initial handshake negotiates a tunnel connection with the proxy, before the stream in encrypted. A Secure Tunnel handshake [TCPPROXY], section 3.1, stipulates that once the handshake is finished, all subsequent data is to be ignored by the proxy, with the intent that all data after the plaintext handshake is SSL encrypted. From this point onward the Secure Tunnel Proxy Protocol simply proxies the application data stream between the client and server. This specification substitutes an SSTP data steam for the SSL data stream after completion of the Secure Tunnel handshake.
The Secure Tunnel Proxy Protocol has evolved over time to become a general purpose tunnel mechanism for permitting non-HTTP protocols, such as SSTP, to traverse an HTTP proxy. The following figure shows this tunnel mechanism. The Secure Tunnel Proxy can listen on any port while the Connect Method allows clients to select any target port on the remote server. The application data that follows the Connection Method handshake can be an SSL data stream or any data stream. SSL encryption is optional, but some Secure Tunnel Proxy implementations still attempt to validate the presence of an SSL handshake within the data stream to provide increased security.
Figure 10: Relationship of SSTP connections/sessions and Secure Tunnel Proxy handshake
In this specification a Secure Tunnel connection is used to explicitly traverse firewall and proxies where direct connections are not possible. Although the Secure Tunnel handshake uses HTTP, the application data following the Secure Tunnel proxy protocol handshake contains the SSTP data stream. The SSTP data stream is possible because the proxy treats all data following the handshake as SSL data which implicitly cannot be decrypted. The SSTP data stream does not need the added security provided by SSL because it has already been authenticated by SSTP Security [MS-GRVSSTPS] and encrypted and integrity protected by the SSTP application layer.
During the Secure Tunnel connection handshake, the client specifies the server’s well known port 443/TCP. Although the SSTP 2492/TCP port could have been specified, port 443/TCP is used in favor of 2492/TCP to avoid firewall and proxy configurations that block the Secure Tunnel Proxy connections on ports other than 443/TCP. Although the secure tunnel connection uses port 443/TCP, which is the well-known SSL port, the connection does not use the SSL protocol and the server does not support the SSL handshake on the port.
A server has no knowledge that it is communicating with a Secure Tunnel Proxy. Meanwhile the Secure Tunnel Proxy has no knowledge that it is communicating using the SSTP Protocol [MS-GRVSSTP].
A variant of the Secure Tunnel Proxy Protocol is used by the client for direct end-to-end communication when no intermediate proxy is involved. The client connections to the server use the well-known SSL 443/TCP port to send and receive SSTP protocol messages. In this case, the client requires that the server’s SSL Tunnel listener does not support SSL handshake or SSL messages. The client requires that the SSL listener is essentially the same as the SSTP listener except it uses the SSL port. This mode is referred to as SSTP over SSL, which defines a technique, not a protocol.