- From: Ari Luotonen <luotonen@netscape.com>
- Date: Fri, 12 Sep 1997 16:04:20 -0700 (PDT)
- To: http-wg mailing list <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
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.
Cheers,
--
Ari Luotonen, Mail-Stop MV-061 Opinions my own, not Netscape's.
Netscape Communications Corp. ari@netscape.com
501 East Middlefield Road http://people.netscape.com/ari/
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.
Abstract
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
httpd).
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
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 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
connection).
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
specified.
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.
Example:
CONNECT home.netscape.com:443 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.
Example:
CONNECT home.netscape.com:443 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.
Example:
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 home.netscape.com:443 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 <ari@netscape.com>
Mail-Stop MV-061
Netscape Communications Corp.
501 E. Middlefield Road
Mountain View, CA 94043
USA
Luotonen [Page 5]
Received on Friday, 12 September 1997 16:09:51 UTC