and hence, not secure.  This may, however, often be acceptable if
       the clients are in a trusted subnetwork (behind a firewall).

     * The proxy will need to have full SSL implementation incorporated




 
TCP PROTOCOL TUNNELING IN WEB PROXY SERVERS INTERNET-DRAFT   August 1998


       into it -- something this tunneling mechanism does not require.

     * The client will not be able to perform SSL client authentication
       (authentication based on X509 certificates) to the remote server,
       as the proxy will be the authenticated party.  Future versions of
       SSL may, however, provide such delegated authentication.

   This specification defines a tunneling mechanism for Web proxy
   servers.  This mechanism is compatible with HTTP/1.x protocol, which
   is currently being used by Web proxies.

   Note that this mechanism, if used for SSL tunneling, does not require
   an implementation of SSL in the proxy.  The SSL session is
   established between the client generating the request, and the
   destination (secure) Web server; the proxy server in between is
   merely tunneling the encrypted data, and does not take any other part
   in the secure transaction.


2. General Considerations with Respect to SSL Tunneling

   When tunneling SSL, the proxy must not have access to the data being
   transferred in either direction, for the 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
   user.

   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 backward
   compatible, the handshake must be in the same format as HTTP/1.x
   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
   connection).


3. Functional Specification



3.1. Request

   The client connects to the proxy server, 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 specified.





 
TCP PROTOCOL TUNNELING IN WEB PROXY SERVERS INTERNET-DRAFT   August 1998


   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.  Note that some applications may use just a LF on its own, and
   it is recommended that applications be tolerant of this behavior.
   When this document refers to CR LF pair, in all cases should a LF on
   its own be treated the same as a CR LF pair).

   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.  The empty line is simply another CR LF
   pair.

   After the empty line, if the handshake to establish the connection
   was successful, the tunnelled (SSL or other) data transfer can begin.
   Before the tunneling begins, the proxy will respond, as described in
   the next section (Section 3.2).

   Example of an SSL tunneling request to host home.netscape.com, to
   HTTPS port (443):

         CONNECT home.netscape.com:443 HTTP/1.0
         User-agent: Mozilla/4.0

         ...data to be tunnelled to the server...

   Note that the "...data to be tunnelled to the server..." is not a
   part of the request.  It is shown here only to make the point that
   once the tunnel is established, the same connection is used for
   transferring the data that is to be tunnelled.

   The advantage of extending the HTTP/1.x protocol in this manner (a
   new method) is that this protocol is freely extensible just like