draft-ietf-tls-http-upgrade-01.txt   draft-ietf-tls-http-upgrade-02.txt 
Network Working Group R. Khare Network Working Group R. Khare
Internet-Draft 4K Associates / UC Irvine Internet-Draft 4K Associates / UC Irvine
Expires: December 21, 1999 S. Lawrence Expires: February 15, 2000 S. Lawrence
Agranat Systems, Inc. Agranat Systems, Inc.
June 22, 1999 August 17, 1999
Upgrading to TLS Within HTTP/1.1 Upgrading to TLS Within HTTP/1.1
draft-ietf-tls-http-upgrade-01.txt draft-ietf-tls-http-upgrade-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 21, 1999. This Internet-Draft will expire on February 15, 2000.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract Abstract
This memo applies the Upgrade mechanism in HTTP/1.1 to employ This memo explains how to use the Upgrade mechanism in HTTP/1.1 to
Transport Layer Security (TLS) over an existing TCP connection. This initiate Transport Layer Security (TLS) over an existing TCP
allows unsecured and secured traffic to share the same well known connection. This allows unsecured and secured HTTP traffic to share
port (in this case, http: at 80 rather than https: at 443). This the same well known port (in this case, http: at 80 rather than
also enables "virtual hosting," by allowing a single HTTP + TLS https: at 443). It also enables "virtual hosting," so a single HTTP
server to disambiguate traffic intended for several hostnames at a + TLS server can disambiguate traffic intended for several hostnames
single IP address. at a single IP address.
This memo also clarifies how to exploit the HTTP/1.1 Upgrade Since HTTP/1.1[1] defines Upgrade as a hop-by-hop mechanism, this
mechanism in general. It creates new IANA registries for public HTTP memo also documents the HTTP CONNECT method for establishing
status codes, and public or private Upgrade product tokens. end-to-end tunnels across HTTP proxies. Finally, this memo
establishes new IANA registries for public HTTP status codes, as
well as public or private Upgrade product tokens.
This memo also argues that 'https' is insufficient to discriminate This memo does NOT affect the current definition of the 'https' URI
between secure and non-secure URIs, and henceforth http: alone scheme, which already defines a separate namespace
should be used. That is to say, both https: and port 443 could be (http://example.org/ and https://example.org/ are not equivalent).
safely deprecated upon deployment of this mechanism.
Status Notes Status Notes
This memo is intended to proceed directly to Proposed Standard, This memo is intended to proceed directly to Proposed Standard,
since its functionality has been extensively debated, but not since its functionality has been extensively debated, but not
implemented, over the last two years. It is expected to update RFC implemented, over the last two years. It is expected to update RFC
2616. 2616.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Table of Contents Table of Contents
1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Client Requested Upgrade to HTTP over TLS . . . . . . . . . . 4 3. Client Requested Upgrade to HTTP over TLS . . . . . . . . . . 4
3.1 Requesting Upgrade When Unsecured Is Not Acceptable . . . . . 4 3.1 Optional Upgrade . . . . . . . . . . . . . . . . . . . . . . . 4
3.2 Requesting Upgrade When Unsecured Is Acceptable . . . . . . . 4 3.2 Mandatory Upgrade . . . . . . . . . . . . . . . . . . . . . . 4
3.3 Server Acceptance of Upgrade Request . . . . . . . . . . . . . 5 3.3 Server Acceptance of Upgrade Request . . . . . . . . . . . . . 5
4. Server Requested Upgrade to HTTP over TLS . . . . . . . . . . 5 4. Server Requested Upgrade to HTTP over TLS . . . . . . . . . . 5
4.1 Server Required Upgrade to HTTP over TLS . . . . . . . . . . . 5 4.1 Optional Advertisement . . . . . . . . . . . . . . . . . . . . 5
4.2 Server Advertised HTTP over TLS . . . . . . . . . . . . . . . 6 4.2 Mandatory Advertisement . . . . . . . . . . . . . . . . . . . 5
5. HTTP Upgrade Usage Considerations . . . . . . . . . . . . . . 6 5. Upgrade across Proxies . . . . . . . . . . . . . . . . . . . . 6
5.1 Upgrading across HTTP Proxies . . . . . . . . . . . . . . . . 6 5.1 Implications of Hop By Hop Upgrade . . . . . . . . . . . . . . 6
6. Rationale for the use of a 4xx (client error) response code . 7 5.2 Requesting a Tunnel with CONNECT . . . . . . . . . . . . . . . 6
7. Rationale for the HTTP+TLS/1.0 Upgrade token . . . . . . . . . 7 5.3 Establishing a Tunnel with CONNECT . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. Rationale for the use of a 4xx (client error) Status Code . . 8
8.1 HTTP Status Code Registry . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8.2 HTTP Upgrade Token Registry . . . . . . . . . . . . . . . . . 8 7.1 HTTP Status Code Registry . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7.2 HTTP Upgrade Token Registry . . . . . . . . . . . . . . . . . 8
9.1 Implications for the https: URI Scheme . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8.1 Implications for the https: URI Scheme . . . . . . . . . . . . 10
8.2 Security Considerations for CONNECT . . . . . . . . . . . . . 10
References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13
1. Motivation 1. Motivation
The historical practice for deploying HTTP over SSL3[2] has The historical practice of deploying HTTP over SSL3 [3] has
distinguished the combination from HTTP alone by a unique URI scheme distinguished the combination from HTTP alone by a unique URI scheme
and the TCP port number. The scheme 'http' meant the HTTP protocol and the TCP port number. The scheme 'http' meant the HTTP protocol
alone on port 80, while 'https' meant the HTTP protocol over SSL on alone on port 80, while 'https' meant the HTTP protocol over SSL on
port 443. Other protocols have similarly requested (and in some port 443. Parallel well-known port numbers have similarly been
cases were issued) a second well known port so that they can requested -- and in some cases, granted -- to distinguish between
distinguish the secured and unsecured modes of operation in this way secured and unsecured use of other application protocols (e.g.
as well. Taken to its extreme, this approach in effect cuts in half snews, ftps). This approach effectively halves the number of
the number of available well known ports. available well known ports.
At the Washington DC IETF meeting in December 1997, the Applications At the Washington DC IETF meeting in December 1997, the Applications
Area Directors, and the IESG broadly, reaffirmed that the practice Area Directors and the IESG reaffirmed that the practice of issuing
of issuing parallel "secure" port numbers should be deprecated. The parallel "secure" port numbers should be deprecated. The HTTP/1.1
HTTP/1.1 Upgrade mechanism can indeed apply Transport Layer Upgrade mechanism can apply Transport Layer Security[6] to an open
Security[5] to an HTTP connection, over the same port. HTTP connection.
In the nearly two years since, there has been broad acceptance of In the nearly two years since, there has been broad acceptance of
the concept behind this proposal, but little interest in the concept behind this proposal, but little interest in
implementing alternatives to port 443 for generic Web browsing. implementing alternatives to port 443 for generic Web browsing. In
However, the Internet Printing Protocol[6], one of the first new fact, nothing in this memo affects the current interpretation of
application protocols built atop HTTP, has called for just such a https: URIs. However, new application protocols built atop HTTP,
mechanism in order to move forward in the IETF standards process. such as the Internet Printing Protocol[7], call for just such a
mechanism in order to move ahead in the IETF standards process.
The Upgrade mechanism also solves the "virtual hosting" problem. The Upgrade mechanism also solves the "virtual hosting" problem.
Rather than allocating multiple IP addresses to a single host, an Rather than allocating multiple IP addresses to a single host, an
HTTP/1.1 server will use the Host: header to disambiguate the HTTP/1.1 server will use the Host: header to disambiguate the
intended web service. As HTTP/1.1 usage has grown more prevalent, intended web service. As HTTP/1.1 usage has grown more prevalent,
more ISPs are offering name-based virtual hosting, thus delaying IP more ISPs are offering name-based virtual hosting, thus delaying IP
address space exhaustion. address space exhaustion.
TLS (and SSL) have been hobbled by the same limitation as earlier TLS (and SSL) have been hobbled by the same limitation as earlier
versions of HTTP: the initial handshake does not specify the versions of HTTP: the initial handshake does not specify the
intended hostname, relying exclusively on the IP address. Using a intended hostname, relying exclusively on the IP address. Using a
cleartext HTTP/1.1 Upgrade: preamble to the TLS handshake -- cleartext HTTP/1.1 Upgrade: preamble to the TLS handshake --
choosing the certificates based on the initial Host: header -- will choosing the certificates based on the initial Host: header -- will
allow ISPs to provide secure name-based virtual hosting as well. allow ISPs to provide secure name-based virtual hosting as well.
2. Introduction 2. Introduction
Either the client or server can use the HTTP/1.1[1] Upgrade
mechanism (Section 14.42) to indicate that a TLS-secured connection
is desired or necessary. This draft defines the "HTTP+TLS/1.0"
Upgrade token and a new HTTP Reply Code, "426 Upgrade Required".
TLS, a/k/a SSL (Secure Sockets Layer) establishes a private TLS, a/k/a SSL (Secure Sockets Layer) establishes a private
end-to-end connection, optionally including strong mutual end-to-end connection, optionally including strong mutual
authentication, using a variety of cryptosystems. Initially, a authentication, using a variety of cryptosystems. Initially, a
handshake phase uses three subprotocols to set up a record layer, handshake phase uses three subprotocols to set up a record layer,
authenticate endpoints, set parameters, as well as report errors. authenticate endpoints, set parameters, as well as report errors.
Then, there is an ongoing layered record protocol that handles Then, there is an ongoing layered record protocol that handles
encryption, compression, and reassembly for the remainder of the encryption, compression, and reassembly for the remainder of the
connection. The latter is intended to be completely transparent. For connection. The latter is intended to be completely transparent. For
example, there is no dependency between TLS's record markers and or example, there is no dependency between TLS's record markers and or
certificates and HTTP/1.1's chunked encoding or authentication. certificates and HTTP/1.1's chunked encoding or authentication.
This specification provides a procedure for either a client or
server to request that this TLS handshake phase begin on an existing
HTTP/1.1 connection.
3. Client Requested Upgrade to HTTP over TLS
The client sends an HTTP/1.1 request with an Upgrade header field Either the client or server can use the HTTP/1.1[1] Upgrade
containing the token "HTTP+TLS/1.0". mechanism (Section 14.42) to indicate that a TLS-secured connection
is desired or necessary. This draft defines the "TLS/1.0" Upgrade
3.1 Requesting Upgrade When Unsecured Is Not Acceptable token, and a new HTTP Status Code, "426 Upgrade Required".
To complete the switch to secured operation before sending any clear Section 3 and Section 4 describe the operation of a directly
HTTP traffic, the client MAY use a method such as "OPTIONS*". connected client and server. Intermediate proxies must establish an
end-to-end tunnel before applying those operations, as explained in
Section 5.
OPTIONS * HTTP/1.1 3. Client Requested Upgrade to HTTP over TLS
Host: bank.example.com
Upgrade: HTTP+TLS/1.0
Connection: Upgrade
The client MUST use the OPTIONS method if unsecured operation is When the client sends an HTTP/1.1 request with an Upgrade header
unacceptable. field containing the token "TLS/1.0", it is requesting the server to
complete the current HTTP/1.1 request after switching to TLS/1.0.
3.2 Requesting Upgrade When Unsecured Is Acceptable 3.1 Optional Upgrade
The client MAY offer to switch to secured operation during a clear A client MAY offer to switch to secured operation during any clear
HTTP operation: HTTP request when an unsecured response would be acceptable:
GET http://bank.example.com/acct_stat.html?749394889300 HTTP/1.1 GET http://example.bank.com/acct_stat.html?749394889300 HTTP/1.1
Host: bank.example.com Host: example.bank.com
Upgrade: HTTP+TLS/1.0 Upgrade: TLS/1.0
Connection: Upgrade Connection: Upgrade
In this case, the server MAY respond to the clear HTTP operation In this case, the server MAY respond to the clear HTTP operation
normally, OR switch to secured operation (as detailed in the next normally, OR switch to secured operation (as detailed in the next
section). section).
Note that HTTP/1.1[1] specifies "the upgrade keyword MUST be
supplied within a Connection header field (section 14.10) whenever
Upgrade is present in an HTTP/1.1 message."
3.2 Mandatory Upgrade
If an unsecured response would be unacceptable, a client MUST send
an OPTIONS request first to complete the switch to TLS/1.0 (if
possible).
OPTIONS * HTTP/1.1
Host: example.bank.com
Upgrade: TLS/1.0
Connection: Upgrade
3.3 Server Acceptance of Upgrade Request 3.3 Server Acceptance of Upgrade Request
As specified in HTTP/1.1[1], if the server is prepared to initiate As specified in HTTP/1.1[1], if the server is prepared to initiate
the TLS handshake, it MUST send the intermediate "101 Switching the TLS handshake, it MUST send the intermediate "101 Switching
Protocol" response specifying the upgrade tokens it is switching to: Protocol" and MUST include an Upgrade response header specifying the
tokens of the protocol stack it is switching to:
HTTP/1.1 101 Switching Protocols HTTP/1.1 101 Switching Protocols
Upgrade: HTTP+TLS/1.0 Upgrade: TLS/1.0, HTTP/1.1
Connection: Upgrade
The TLS handshake bytes begin after the final CRNL of the HTTP Note that the protocol tokens listed in the Upgrade header of a 101
response. Switching Protocols response specify an ordered 'bottom-up' stack.
If the TLS handshake completes, the server MUST continue with the As specified in HTTP/1.1[1], Section 10.1.2: "The server will
response to the original request. Any TLS handshake failure MUST switch protocols to those defined by the response's Upgrade header
lead to disconnection, per the TLS error alert specification. field immediately after the empty line which terminates the 101
response."
In the 'required upgrade' case described in Section 3.1, the client Once the TLS handshake completes successfully, the server MUST
will send the real request after the OPTIONS ("no-op") request has continue with the response to the original request. Any TLS
completed. handshake failure MUST lead to disconnection, per the TLS error
alert specification.
4. Server Requested Upgrade to HTTP over TLS 4. Server Requested Upgrade to HTTP over TLS
The Upgrade header field can be used in HTTP responses to advertise The Upgrade response header field advertises possible protocol
server policy. upgrades a server MAY accept. In conjunction with the "426 Upgrade
Required" status code, a server can advertise the exact protocol
upgrade(s) that a client MUST accept to complete the request.
4.1 Server Required Upgrade to HTTP over TLS 4.1 Optional Advertisement
A server can indicate that a request can not be fulfilled without As specified in HTTP/1.1[1], the server MAY include an Upgrade
TLS secured operation using the "426 Upgrade Required" status code header in any response other than 101 or 426 to indicate a
[see Section 6 for the rationale for why this is not a 3xx redirect willingness to switch to any (combination) of the protocols listed.
response]. The 426 response MUST include an Upgrade header field
specifying the token for the required TLS version. 4.2 Mandatory Advertisement
A server MAY indicate that a client request can not be completed
without TLS using the "426 Upgrade Required" status code, which MUST
include an an Upgrade header field specifying the token of the
required TLS version.
HTTP/1.1 426 Upgrade Required HTTP/1.1 426 Upgrade Required
Upgrade: HTTP+TLS/1.0 Upgrade: TLS/1.0, HTTP/1.1
... Connection: Upgrade
The server cannot know whether or not the client is willing or able The server SHOULD include a message body in the 426 response which
to Upgrade. The use of 426 means that the request has failed, as any indicates in human readable form the reason for the error and
4xx code would. This has two important implications: describes any alternative courses which may be available to the
1. The server SHOULD include a message body in the 426 response user.
which indicates in human readable form the reason for the error
and describes any alternative courses which may be available to
the user.
2. Neither the server nor the client can immediately begin the TLS
handshake -- a new request must be made, whether over the same
TCP connection or not.
If the client is capable of the protocol set specified by the server Note that even if a client is willing to use TLS, it must use the
in the Upgrade header of a 426 response, it MAY begin a operations in Section 3 to proceed; the TLS handshake cannot begin
client-initiated sequence as specified in Section 3 to repeat the immediately after the 426 response.
request.
[Since the original request was presumably sent in the clear, the 5. Upgrade across Proxies
Section 3.2 method reduce the number of round-trips in this case]
4.2 Server Advertised HTTP over TLS As a hop-by-hop header, Upgrade is negotiated between each pair of
HTTP counterparties. If a User Agent sends a request with an
Upgrade header to a proxy, it is requesting a change to the protocol
between itself and the proxy, not an end-to-end change.
As specified in [HTTP], the server MAY include an Upgrade header in Since TLS, in particular, requires end-to-end connectivity to
any response to indicate a willingness to switch to any provide authentication and prevent man-in-the-middle attacks, this
(combination) of the protocols listed. Only a 101 or 426 response memo specifies the CONNECT method to establish a tunnel across
lists Upgrade tokens that MUST be used to successfully complete the proxies.
request.
5. HTTP Upgrade Usage Considerations Once a tunnel is established, any of the operations in Section 3 can
be used to establish a TLS connection.
In the course of formalizing this mechanism, several principles of 5.1 Implications of Hop By Hop Upgrade
HTTP Upgrade usage have been clarified for future users.
o Servers MUST select at most one of the offered Upgrade tokens in If an origin server receives an Upgrade header from a proxy and
the 101 Switching Protocols response. responds with a 101 Switching Protocols response, it is changing the
o This implies that Upgrade tokens represent "bundles" of protocol only on the connection between the proxy and itself.
functionality. Skipping a sequential upgrade to X/1.0 then to Similarly, a proxy might return a 101 response to its client to
Y/1.0 would require defining a joint XY/1.0 token, for example. change the protocol on that connection independently of the
o This implies public Upgrade tokens should be managed by IANA, protocols it is using to communicate toward the origin server.
according to the process in [8].
o Reliable deployment of new protocol extensions requires a
definitive failure error, "426 Upgrade Required" in this case.
This is broadly useful for any Upgrade usage.
Note that since Upgrade was only defined in HTTP/1.1 (and above), These scenarios also complicate diagnosis of a 426 response. Since
upgraded protocols can assume persistent-connections by default. Upgrade is a hop-by-hop header, a proxy that does not recognize 426
might remove the accompanying Upgrade header and prevent the client
from determining the required protocol switch. If a client receives
a 426 status without an accompanying Upgrade header, it will need to
request an end to end tunnel connection as described in Section 5.2
and repeat the request in order to obtain the required upgrade
information.
5.1 Upgrading across HTTP Proxies This hop-by-hop definition of Upgrade was a deliberate choice. It
allows for incremental deployment on either side of proxies, and for
optimized protocols between cascaded proxies without the knowledge
of the parties that are not a part of the change.
As a hop-by-hop header, Upgrade must be negotiated between each pair 5.2 Requesting a Tunnel with CONNECT
of HTTP counterparties. As an end-to-end protocol, HTTP+TLS/1.0 is
only applicable across tunnels. The HTTP CONNECT method explicitly
constructed a tunnel, but it requires unique port numbers to
disambiguate services.
The following rules apply to relaying Upgrade requests: A CONNECT method requests that a proxy establish a tunnel connection
on its behalf. The Request-URI portion of the Request-Line is always
an 'authority' as defined by URI Generic Syntax[2], which is to say
the host name and port number destination of the requested
connection separated by a colon:
1. Upon receipt of an Upgrade header field, a proxy server MUST CONNECT server.example.com:80 HTTP/1.1
either discard all the offers, or choose to forward only those Host: server.example.com:80
it agrees to become a tunnel for.
2. Upon receipt of a "101 Switching Protocols" response, a proxy
server MUST become a tunnel, or report a more detailed proxy
server error.
Furthermore a caching proxy SHOULD not reply to a request with Other HTTP mechanisms can be used normally with the CONNECT method
Upgrade tokens from its cache. Clients are still advised to -- except end-to-end protocol Upgrade requests, of course, since the
explicitly include "Cache-control: no-cache" in this case. tunnel must be established first.
Note that these scenarios slightly complicate diagnosis of a For example, proxy authentication might be used to establish the
426-status response. Since Upgrade: is a hop-by-hop header, a proxy authority to create a tunnel:
may have removed the client's original Upgrade request, while the
origin server continues to insist no offer was received.
6. Rationale for the use of a 4xx (client error) response code CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80
Proxy-Authorization: basic aGVsbG86d29ybGQ=
Like any other pipelined HTTP/1.1 request, data to be tunneled may
be sent immediately after the blank line. The usual caveats also
apply: data may be discarded if the eventual response is negative,
and the connection may be reset with no response if more than one
TCP segment is outstanding.
5.3 Establishing a Tunnel with CONNECT
Any successful (2xy) response to a CONNECT request indicates that
the proxy has established a connection to the requested host and
port, and has switched to tunneling the current connection to that
server connection.
It may be the case that the proxy itself can only reach the
requested origin server through another proxy. In this case, the
first proxy SHOULD make a CONNECT request of that next proxy,
requesting a tunnel to the authority. A proxy MUST NOT respond with
any 2xy status code unless it has either a direct or tunnel
connection established to the authority.
An origin server which receives a CONNECT request for itself MAY
respond with a 2xy status code to indicate that a connection is
established.
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.
6. Rationale for the use of a 4xx (client error) Status Code
Reliable, interoperable negotiation of Upgrade features requires an Reliable, interoperable negotiation of Upgrade features requires an
unambiguous failure signal. The 426 Upgrade Required status code unambiguous failure signal. The 426 Upgrade Required status code
allows a server to definitively state the precise protocol allows a server to definitively state the precise protocol
extensions a given resource must be served with. Otherwise, there extensions a given resource must be served with.
would be no solution in the Section 4.1 case.
It might at first appear that the response should have been some It might at first appear that the response should have been some
form of redirection (a 3xx code), by analogy to an old-style form of redirection (a 3xx code), by analogy to an old-style
redirection to an https: URI. User agents that do not understand redirection to an https: URI. User agents that do not understand
Upgrade: preclude this: Upgrade: preclude this.
Suppose that the code 3YZ had been assigned for "Upgrade Required"; Suppose that a 3xx code had been assigned for "Upgrade Required"; a
a user agent that did not recognize it would treat it as 300. It user agent that did not recognize it would treat it as 300. It
would then properly look for a "Location" header in the response and would then properly look for a "Location" header in the response and
attempt to repeat the request at the URL in that header field. attempt to repeat the request at the URL in that header field. Since
Since it did not know to Upgrade to HTTP+TLS/1.0, it would at best it did not know to Upgrade to incorporate the TLS layer, it would at
fail again at the new URL. best fail again at the new URL.
7. Rationale for the HTTP+TLS/1.0 Upgrade token
While TLS (and SSL) are properly ignorant of the syntax and
semantics of encapsulated, encrypted traffic, it remains
inappropriate to infer the protocol being secured by TCP port
number. To reinforce the point that the upgraded protocol is now the
composition of HTTP and TLS/1.0, we explicitly named the Upgrade
token HTTP+TLS/1.0.
Note that the version number in the product token refers to the
version of TLS employed; the version of HTTP to be used over TLS
following the switch is calculated normally, viz. per the version
compatibility rules of HTTP. [Note that while TLS is compatible with
previous versions of SSL, they do not have TLS version numbers. If
there were a backwards-compatible Upgrade, it might have specified
HTTP+SSL/3.0 instead.]
Purely HTTP-compliant extensions such as IPP will reuse
HTTP+TLS/1.0, while derivative works such as the Session Initiation
Protocol are encouraged to define their own Upgrade mechanism and
their own tokens.
8. IANA Considerations 7. IANA Considerations
IANA shall create registries for two name spaces, as described in IANA shall create registries for two name spaces, as described in
BCP 26[8]: BCP 26[10]:
o HTTP Status Codes o HTTP Status Codes
o HTTP Upgrade Tokens o HTTP Upgrade Tokens
8.1 HTTP Status Code Registry 7.1 HTTP Status Code Registry
The HTTP Status Code Registry defines the name space for the The HTTP Status Code Registry defines the name space for the
Status-Code token in the Status line of an HTTP response. The Status-Code token in the Status line of an HTTP response. The
initial values for this name space are those specified by initial values for this name space are those specified by
1. Draft Standard for HTTP/1.1[1] 1. Draft Standard for HTTP/1.1[1]
2. Web Distributed Authoring and Versioning[3] [defines 420-424] 2. Web Distributed Authoring and Versioning[4] [defines 420-424]
3. WebDAV Advanced Collections[4] (Work in Progress) [defines 425] 3. WebDAV Advanced Collections[5] (Work in Progress) [defines 425]
4. section Section 6 of this specification.[defines 426] 4. Section 6 [defines 426]
Values to be added to this name space SHOULD be subject to review in Values to be added to this name space SHOULD be subject to review in
the form of a standards track document within the IETF Applications the form of a standards track document within the IETF Applications
Area. Any such document SHOULD be traceable through statuses of Area. Any such document SHOULD be traceable through statuses of
either 'Obsoletes' or 'Updates' to the Draft Standard for either 'Obsoletes' or 'Updates' to the Draft Standard for
HTTP/1.1[1]. HTTP/1.1[1].
8.2 HTTP Upgrade Token Registry 7.2 HTTP Upgrade Token Registry
The HTTP Upgrade Token Registry defines the name space for product The HTTP Upgrade Token Registry defines the name space for product
tokens used to identify protocols in the the Upgrade HTTP header tokens used to identify protocols in the Upgrade HTTP header field.
field. Each registered token should be associated with one or a set Each registered token should be associated with one or a set of
of specifications, and with contact information. specifications, and with contact information.
The Draft Standard for HTTP/1.1[1] specifies that these tokens obey The Draft Standard for HTTP/1.1[1] specifies that these tokens obey
the production for 'product': the production for 'product':
product = token ["/" product-version] product = token ["/" product-version]
product-version = token product-version = token
Registrations should be allowed on a First Come First Served basis Registrations should be allowed on a First Come First Served basis
as described in BCP 26[8]. These specifications need not be IETF as described in BCP 26[10]. These specifications need not be IETF
documents or be subject to IESG review, but should obey the documents or be subject to IESG review, but should obey the
following rules: following rules:
1. The registration for a given token MUST NOT be changed once 1. The registration for a given token MUST NOT be changed once
registered. registered.
2. The registry MUST NOT register a token whose 'product' component 2. The registry MUST NOT register a token whose 'product' component
is the same as that of an already registered token, unless the is the same as that of an already registered token, unless the
source of the authority for the registration is the same as the source of the authority for the registration is the same as the
previous registry (if company XYZ, Inc. registered "XYZ/1.0", previous registry (if company XYZ, Inc. registered "XYZ/1.0",
then no other entity should be allowed to register any token then no other entity should be allowed to register any token
whose product component is "XYZ" without the consent of XYZ, Inc. whose product component is "XYZ" without the consent of XYZ, Inc.
An initial value in this namespace is defined in Section Section 7 This specification defines the protocol token "TLS/1.0" as the
of this specification. identifier for the protocol specified by The TLS Protocol[6].
It is NOT required that specifications for upgrade tokens be made It is NOT required that specifications for upgrade tokens be made
publically available, but the contact information for the publicly available, but the contact information for the registration
registration SHOULD be. SHOULD be.
9. Security Considerations 8. Security Considerations
The potential for a man-in-the-middle attack (deleting the The potential for a man-in-the-middle attack (deleting the Upgrade
HTTP+TLS/1.0 upgrade token) remains the same as current, mixed header) remains the same as current, mixed http/https practice:
http/https practice: o Removing the Upgrade header is similar to rewriting web pages to
o Removing the Upgrade token is similar to rewriting web pages to
change https:// links to http:// links. change https:// links to http:// links.
o The risk is only present if the server is willing to vend that o The risk is only present if the server is willing to vend such
information over both a secure and an insecure channel in the information over both a secure and an insecure channel in the
first place. first place.
o If the client knows for a fact that a server is TLS-compliant, it o If the client knows for a fact that a server is TLS-compliant, it
can insist on it by only connecting as https: (currently) or by can insist on it by only sending an Upgrade request with a no-op
only sending an Upgrade request with a no-op method like OPTIONS. method like OPTIONS.
o Finally, as the https: specification warns, "users should o Finally, as the https: specification warns, "users should
carefully examine the certificate presented by the server to carefully examine the certificate presented by the server to
determine if it meets their expectations." -- there is no determine if it meets their expectations."
substitute for vigilance.
Furthermore, for clients which do not actively try to invoke TLS, Furthermore, for clients that do not explicitly try to invoke TLS,
servers can use Upgrade: to advertise TLS compliance, too. Since servers can use the Upgrade header in any response other than 101 or
TLS-compliance should be considered a feature of the server and not 426 to advertise TLS compliance. Since TLS compliance should be
the resource at hand, it should be sufficient to send it once, and considered a feature of the server and not the resource at hand, it
let clients cache that fact. should be sufficient to send it once, and let clients cache that
fact.
9.1 Implications for the https: URI Scheme 8.1 Implications for the https: URI Scheme
This mechanism does not use the URI scheme name to indicate the While nothing in this memo affects the definition of the 'https' URI
protocol used. That is, any http: URI could be upgraded; and that scheme, widespread adoption of this mechanism for HyperText content
https: URIs are no guarantee the server will upgrade. could use 'http' to identify both secure and non-secure resources.
Instead, the choice of what security characteristics are required on The choice of what security characteristics are required on the
the connection is left to the client and server. This allows either connection is left to the client and server. This allows either
party to use any information available in making this determination. party to use any information available in making this determination.
For example, user agents may rely on user preference settings or For example, user agents may rely on user preference settings or
information about the security of the network such as 'TLS required information about the security of the network such as 'TLS required
on all POST operations not on my local net or VPN', and servers may on all POST operations not on my local net', or servers may apply
resource access rules such as 'the form on this page must be served resource access rules such as 'the FORM on this page must be served
and submitted using TLS'. and submitted using TLS'.
This also implies both parties have the option of fallback to a less 8.2 Security Considerations for CONNECT
secure mode of operation if either party cannot shift to TLS and
such unsecured operation is acceptable to both and to the human A generic TCP tunnel is fraught with security risks. First, such
user; this is not possible with the 'https' scheme. authorization should be limited to a small number of known ports.
The Upgrade: mechanism defined here only requires onward tunneling
at port 80. Second, since tunneled data is opaque to the proxy,
there are additional risks to tunneling to other well-known or
reserved ports. A putative HTTP client CONNECTing to port 25 could
relay spam via SMTP, for example.
References References
[1] Fielding, R.T., et. al, , "Hypertext Transfer Protocol -- [1] Fielding, R.T. and et. al, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999. HTTP/1.1", RFC 2616, June 1999.
[2] Rescorla, E.K., "HTTP Over TLS", Internet-Draft (Work In [2] Berners-Lee, T., Fielding, R.T. and L. Masinter, "URI Generic
Progress), September 1998. Syntax", RFC 2396, August 1998.
[3] Goland, Y.Y., Whitehead, E.J., et. al, , "Web Distributed [3] Rescorla, E.K., "HTTP Over TLS", Internet-Draft (Work In
Progress) draft-ietf-tls-https-02, September 1998.
[4] Goland, Y.Y., Whitehead, E.J. and et. al, "Web Distributed
Authoring and Versioning", RFC 2518, February 1999. Authoring and Versioning", RFC 2518, February 1999.
[4] Slein, J., Whitehead, E.J., et. al, , "WebDAV Advanced [5] Slein, J., Whitehead, E.J. and et. al, "WebDAV Advanced
Collections Protocol", Internet-Draft (Work in Progress), June Collections Protocol", Internet-Draft (Work In Progress)
1999. draft-ietf-webdav-collection-protocol-04, June 1999.
[5] Dierks, T., Allen, C., "The TLS Protocol", RFC 2246, January [6] Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, January
1999. 1999.
[6] Herriot, R., Butler, S., Moore, P., Turner, R., "Internet [7] Herriot, R., Butler, S., Moore, P. and R. Turner, "Internet
Printing Protocol/1.0: Encoding and Transport", RFC 2565, April Printing Protocol/1.0: Encoding and Transport", RFC 2565, April
1999. 1999.
[7] Rose, M.T., "Writing I-Ds and RFCs using XML", April 1999. [8] Luotonen, A., "Tunneling TCP based protocols through Web proxy
servers", Internet-Draft (Work In Progress)
draft-luotonen-web-proxy-tunneling-01, August 1998.
[8] Narten, T., Alvestrand, H., "Guidelines for Writing an IANA [9] Rose, M.T., "Writing I-Ds and RFCs using XML", RFC 2629, June
Considerations Section in RFCs", BCP 26, October 1998. 1999.
[10] Narten, T. and H.T. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, October 1998.
Authors' Addresses Authors' Addresses
Rohit Khare Rohit Khare
4K Associates / UC Irvine 4K Associates / UC Irvine
3207 Palo Verde 3207 Palo Verde
Irvine, CA 92612 Irvine, CA 92612
US US
Phone: +1 626 806 7574 Phone: +1 626 806 7574
skipping to change at page 11, line 17 skipping to change at page 11, line 40
Suite 400 Suite 400
Maynard, MA 01754 Maynard, MA 01754
US US
Phone: +1 978 461 0888 Phone: +1 978 461 0888
EMail: lawrence@agranat.com EMail: lawrence@agranat.com
URI: http://www.agranat.com/ URI: http://www.agranat.com/
Appendix A. Acknowledgments Appendix A. Acknowledgments
Thanks to: The CONNECT method was originally described in an Internet-Draft
titled Tunneling TCP based protocols through Web proxy servers[8] by
Ari Luotonen of Netscape Communications Corporation. It was widely
implemented by HTTP proxies, but was never made a part of any IETF
Standards Track document. The method name CONNECT was reserved, but
not defined in [1].
The definition provided here is derived directly from that earlier
draft, with some editorial changes and conformance to the stylistic
conventions since established in other HTTP specifications.
Additional Thanks to:
o Paul Hoffman for his work on the STARTTLS command extension for o Paul Hoffman for his work on the STARTTLS command extension for
ESMTP. ESMTP.
o Roy Fielding for assistance with the rationale behind Upgrade: o Roy Fielding for assistance with the rationale behind Upgrade:
and its interaction with OPTIONS. and its interaction with OPTIONS.
o Eric Rescorla for his work on standardizing the existing https: o Eric Rescorla for his work on standardizing the existing https:
practice to compare with. practice to compare with.
o Marshall Rose, for the xml2rfc document type description and o Marshall Rose, for the xml2rfc document type description and
tools. tools[9].
o Jim Whitehead, for sorting out the current range of available o Jim Whitehead, for sorting out the current range of available
HTTP status codes. HTTP status codes.
o Henrik Frystyk Nielsen, whose work on the Mandatory extension
mechanism pointed out a hop-by-hop Upgrade still requires
tunneling.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published or assist in its implmentation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph
skipping to change at line 520 skipping to change at page 13, line 32
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC editor function is currently provided by the
Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/