SSL Tunneling; Informational RFC; Last call?

I would like to issue a Last Call for the SSL Tunneling spec (included
below), in order to move it into the Informational RFC state.  The
spec has remained virtually unchanged for two I-D rounds (current
draft-luotonen-ssl-tunneling-03.txt expires on 9/26/97), so I believe
there is consensus and it accurately describes the current behaviour.

Of course, the fast-evolveing Web and new requirements on security
impose new requirements on SSL tunneling as well; however, these
issues shall be addressed in subsequent major revisions of this
standard, and should not hold back making this an Informational RFC
ASAP to form a base line, so we can move on.

Ari Luotonen, Mail-Stop MV-061		Opinions my own, not Netscape's.
Netscape Communications Corp.
501 East Middlefield Road
Mountain View, CA 94043, USA		Netscape Proxy Server Development


Network Working Group                                       Ari Luotonen
Request for Comments: XXXX           Netscape Communications Corporation
Category: Informational                                  September, 1997

                Tunneling SSL through Web Proxy Servers

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.


   This document specifies a tunneling mechanism for SSL through Web
   proxy servers.  This tunneling mechanism is not specific to SSL, but
   may in fact be used for tunneling any TCP based protocol.  It is
   expected that future revisions of this protocol awknowledge the full
   potential of this tunneling mechanism, and change its name to be more
   generic, decoupling it from SSL.  The purpose of this document is to
   describe the current practice used for tunneling SSL through proxies,
   so it will maintain the name that was first used when the SSL
   tunneling protocol was introduced.

Table of Contents

     1. Overview ................................................... 1
     2. General Considerations ..................................... 2
     3. The CONNECT Method ......................................... 2
     4. Proxy Response ............................................. 3
     5. Security Considerations .................................... 4
     6. Extensibility .............................................. 4
     7. Multiple Proxy Servers ..................................... 5
     8. References ................................................. 5
     9. Author's Address ........................................... 5

1. Overview

   The wide success of SSL (Secure Sockets Layer from Netscape
   Communications Corporation) has made it vital that the current WWW
   proxy protocol be extended to allow an SSL client to open a secure

Luotonen                                                        [Page 1]
SSL TUNNELING INTERNET-DRAFT                              September 1997

   tunnel through the proxy.

   The HTTPS protocol, which is just HTTP on top of SSL, can be proxied
   in the same way that currently other protocols are handled by the
   proxies: to have the proxy initiate a secure session with the remote
   HTTPS server, and then perform the HTTPS transaction. This is the way
   FTP and Gopher get handled by proxies, too. However, this approach
   has two disadvantages:

     * The connection between the client and the proxy is normal HTTP,
       and hence, not secure. This is, however, often acceptable if the
       clients are in a trusted subnet (behind a firewall).

     * The proxy will need to have full SSL implementation incorporated
       into it.

   This document describes a way to do SSL tunneling without an
   implementation of SSL, in a way that is compatible with the current
   WWW proxy protocol (as defined by the HTTP/1.0 specification). The
   existing implementation of SSL tunneling in the Netscape Navigator
   and the Netscape Proxy Server conform to this specification. A patch
   implementing this feature also exists for the CERN proxy server (CERN

2. General Considerations

   When tunneling SSL, the proxy must not have access to the data being
   transferred in either direction, for sake of security. The proxy
   merely knows the source and destination addresses, and possibly, if
   the proxy supports user authentication, the name of the requesting

   In other words, there is a handshake between the client and the proxy
   to establish the connection between the client and the remote server
   through the proxy. In order to make this extension be backwords
   compatible, the handshake must be in the same format as HTTP/1.0
   requests, so that proxies without support for this feature can still
   cleanly determine the request as impossible for them to service, and
   give proper error responses (rather than e.g. get hung on the

   SSL tunneling isn't really SSL specific -- it's a general way to have
   a third party establish a connection between two points, after which
   bytes are simply copied back and forth by this intermediary.

   When SSL tunneling support is put into the SSL source code, it will
   work for any SSL enhanced application.

Luotonen                                                        [Page 2]
SSL TUNNELING INTERNET-DRAFT                              September 1997

3. The CONNECT Method

   The client connects to the proxy, and uses the CONNECT method to
   specify the hostname and the port number to connect to. The hostname
   and port number are separated by a colon, and both of them must be

   The host:port part is followed by a space and a string specifying the
   HTTP version number, e.g. HTTP/1.0, and the line terminator (CR LF
   pair, or a single LF).

   After that there is a series of zero or more of HTTP request header
   lines, followed by an empty line. Each of those header lines is also
   terminated by the CR LF pair, or a single LF. The empty line is
   simply another CR LF pair, or another LF.

   After the empty line, if the handshake to establish the connection
   was successful, SSL data transfer can begin.


         CONNECT HTTP/1.0
         User-agent: Mozilla/4.0

         ...SSL data...

   The advantage of this approach is that this protocol is freely
   extensible; for example, the proxy authentication can be used.

         CONNECT HTTP/1.0
         User-agent: Mozilla/4.0
         Proxy-authorization: basic dGVzdDp0ZXN0

         ...SSL data...

4. Proxy Response

   After the empty line in the request, the client will wait for a
   response from the proxy. The proxy will evaluate the request, make
   sure that it is valid, and that the user is authorized to request
   such a connection. If everything is in order, the proxy will make a
   connection to the destination server, and, if successful, send a "200
   Connection established" response to the client. Again, the response
   follows the HTTP/1.0 protocol, so the response line starts with the
   protocol version specifier, and the response line is followed by zero
   or more response headers, followed by an empty line. The line

Luotonen                                                        [Page 3]
SSL TUNNELING INTERNET-DRAFT                              September 1997

   separator is CR LF pair, or a single LF.


         HTTP/1.0 200 Connection established
         Proxy-agent: Netscape-Proxy/1.1

         ...SSL data...

   After the empty line, the proxy will start passing data from the
   client connection to the remote server connection, and vice versa. At
   any time, there may be data coming from either connection, and that
   data should be forwarded to the other connection immediately.

   If at any point either one of the peers gets disconnected, any
   outstanding data that came from that peer will be passed to the other
   one, and after that also the other connection will be terminated by
   the proxy. If there is outstanding data to that peer undelivered,
   that data will be discarded.

5. Security Considerations

   CONNECT is really a lower-level function than the rest of the HTTP
   methods, kind of an escape mechanism for saying that the proxy should
   not interfere with the transaction, but merely forward the data. This
   is because the proxy should not need to know the entire URI that is
   being accessed (privacy, security), only the information that it
   explicitly needs (hostname and port number). Due to this fact, the
   proxy cannot verify that the protocol being spoken is really SSL, and
   so the proxy configuration should explicitly limit allowed
   connections to well-known SSL ports (such as 443 for HTTPS, 563 for
   SNEWS, as assigned by the Internet Assigned Numbers Authority).

6. Extensibility

   The SSL tunneling handshake is freely extensible using the HTTP/1.0
   headers; as an example, to enforce authentication for the proxy the
   proxy will simply use the 407 status code and the Proxy-authenticate
   response header (as defined by the HTTP/1.0 specification) to ask the
   client to send authentication information:

         HTTP/1.0 407 Proxy authentication required
         Proxy-authenticate: ...

         ...SSL data...

Luotonen                                                        [Page 4]
SSL TUNNELING INTERNET-DRAFT                              September 1997

   The client would then send the authentication information in the
   Proxy-authorization header:

         CONNECT HTTP/1.0
         User-agent: ...
         Proxy-authorization: ...

         ...SSL data...

7. Multiple Proxy Servers

   This specification applies also to proxy servers talking to other
   proxy servers.  As an example, double firewalls make this necessary.
   In this case, the inner proxy is simply considered a client with
   respect to the outer proxy.

8. References

   [HTTP/1.0] T. Berners-Lee, R. Fielding, H. Frystyk, "Hypertext
              Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.

   [HTTP/1.1] R. Fiedling et al, "Hypertext Transfer Protocol --
              HTTP/1.1", RFC 2068, January 1997.

   [SSL]      K. Hickman, T. Elgamal, "The SSL Protocol",
              draft-hickman-netscape-ssl-01.txt, Netscape Communications
              Corporation, June 1995

   [SSL3]     A. O. Freier, P. Karlton, Paul C. Kocher,
              "The SSL Protocol -- Version 3.0",
              draft-ietf-tls-ssl-version3-00.txt, November 18, 1996

9. Author's Address:

   Ari Luotonen                                       <>
   Mail-Stop MV-061
   Netscape Communications Corp.
   501 E. Middlefield Road
   Mountain View, CA 94043

Luotonen                                                        [Page 5]

Received on Friday, 12 September 1997 16:09:51 UTC