rfc2817.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                           R. Khare
Request for Comments: 2817                     4K Associates / UC Irvine
Updates: 2616                                                S. Lawrence
Category: Standards Track                          Agranat Systems, Inc.
                                                                May 2000


                    Upgrading to TLS Within HTTP/1.1

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.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   This memo explains how to use the Upgrade mechanism in HTTP/1.1 to
   initiate Transport Layer Security (TLS) over an existing TCP
   connection. This allows unsecured and secured HTTP traffic to share
   the same well known port (in this case, http: at 80 rather than
   https: at 443). It also enables "virtual hosting", so a single HTTP +
   TLS server can disambiguate traffic intended for several hostnames at
   a single IP address.

   Since HTTP/1.1 [1] defines Upgrade as a hop-by-hop mechanism, this
   memo also documents the HTTP CONNECT method for establishing 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 does NOT affect the current definition of the 'https' URI
   scheme, which already defines a separate namespace
   (http://example.org/ and https://example.org/ are not equivalent).











Khare & Lawrence            Standards Track                     [Page 1]

RFC 2817                  HTTP Upgrade to TLS                   May 2000


Table of Contents

   1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.1 Requirements Terminology . . . . . . . . . . . . . . . . . . .  4
   3.  Client Requested Upgrade to HTTP over TLS  . . . . . . . . . .  4
   3.1 Optional Upgrade . . . . . . . . . . . . . . . . . . . . . . .  4
   3.2 Mandatory Upgrade  . . . . . . . . . . . . . . . . . . . . . .  4
   3.3 Server Acceptance of Upgrade Request . . . . . . . . . . . . .  4
   4.  Server Requested Upgrade to HTTP over TLS  . . . . . . . . . .  5
   4.1 Optional Advertisement . . . . . . . . . . . . . . . . . . . .  5
   4.2 Mandatory Advertisement  . . . . . . . . . . . . . . . . . . .  5
   5.  Upgrade across Proxies . . . . . . . . . . . . . . . . . . . .  6
   5.1 Implications of Hop By Hop Upgrade . . . . . . . . . . . . . .  6
   5.2 Requesting a Tunnel with CONNECT . . . . . . . . . . . . . . .  6
   5.3 Establishing a Tunnel with CONNECT . . . . . . . . . . . . . .  7
   6.  Rationale for the use of a 4xx (client error) Status Code  . .  7
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   7.1 HTTP Status Code Registry  . . . . . . . . . . . . . . . . . .  8
   7.2 HTTP Upgrade Token Registry  . . . . . . . . . . . . . . . . .  8
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   8.1 Implications for the https: URI Scheme . . . . . . . . . . . . 10
   8.2 Security Considerations for CONNECT  . . . . . . . . . . . . . 10
       References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
   A.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 12
       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13

1. Motivation

   The historical practice of deploying HTTP over SSL3 [3] has
   distinguished the combination from HTTP alone by a unique URI scheme
   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
   port 443.  Parallel well-known port numbers have similarly been
   requested -- and in some cases, granted -- to distinguish between
   secured and unsecured use of other application protocols (e.g.
   snews, ftps). This approach effectively halves the number of
   available well known ports.

   At the Washington DC IETF meeting in December 1997, the Applications
   Area Directors and the IESG reaffirmed that the practice of issuing
   parallel "secure" port numbers should be deprecated. The HTTP/1.1
   Upgrade mechanism can apply Transport Layer Security [6] to an open
   HTTP connection.






Khare & Lawrence            Standards Track                     [Page 2]

RFC 2817                  HTTP Upgrade to TLS                   May 2000


   In the nearly two years since, there has been broad acceptance of the
   concept behind this proposal, but little interest in implementing
   alternatives to port 443 for generic Web browsing. In fact, nothing
   in this memo affects the current interpretation of https: URIs.
   However, new application protocols built atop HTTP, 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.
   Rather than allocating multiple IP addresses to a single host, an
   HTTP/1.1 server will use the Host: header to disambiguate the
   intended web service. As HTTP/1.1 usage has grown more prevalent,
   more ISPs are offering name-based virtual hosting, thus delaying IP
   address space exhaustion.

   TLS (and SSL) have been hobbled by the same limitation as earlier
   versions of HTTP: the initial handshake does not specify the intended
   hostname, relying exclusively on the IP address. Using a cleartext
   HTTP/1.1 Upgrade: preamble to the TLS handshake -- choosing the
   certificates based on the initial Host: header -- will allow ISPs to
   provide secure name-based virtual hosting as well.

2. Introduction

   TLS, a.k.a., SSL (Secure Sockets Layer), establishes a private end-
   to-end connection, optionally including strong mutual authentication,
   using a variety of cryptosystems. Initially, a handshake phase uses
   three subprotocols to set up a record layer, authenticate endpoints,
   set parameters, as well as report errors.  Then, there is an ongoing
   layered record protocol that handles encryption, compression, and
   reassembly for the remainder of the connection. The latter is
   intended to be completely transparent. For example, there is no
   dependency between TLS's record markers and or certificates and
   HTTP/1.1's chunked encoding or authentication.

   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 memo defines the "TLS/1.0" Upgrade
   token, and a new HTTP Status Code, "426 Upgrade Required".

   Section 3 and Section 4 describe the operation of a directly
   connected client and server. Intermediate proxies must establish an
   end-to-end tunnel before applying those operations, as explained in
   Section 5.







Khare & Lawrence            Standards Track                     [Page 3]

RFC 2817                  HTTP Upgrade to TLS                   May 2000


2.1 Requirements Terminology

   Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
   "MAY" that appear in this document are to be interpreted as described
   in RFC 2119 [11].

3. Client Requested Upgrade to HTTP over TLS

   When the client sends an HTTP/1.1 request with an Upgrade header
   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.1 Optional Upgrade

   A client MAY offer to switch to secured operation during any clear
   HTTP request when an unsecured response would be acceptable:

       GET http://example.bank.com/acct_stat.html?749394889300 HTTP/1.1
       Host: example.bank.com
       Upgrade: TLS/1.0
       Connection: Upgrade

   In this case, the server MAY respond to the clear HTTP operation
   normally, OR switch to secured operation (as detailed in the next
   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

   As specified in HTTP/1.1 [1], if the server is prepared to initiate
   the TLS handshake, it MUST send the intermediate "101 Switching
   Protocol" and MUST include an Upgrade response header specifying the
   tokens of the protocol stack it is switching to:




Khare & Lawrence            Standards Track                     [Page 4]

RFC 2817                  HTTP Upgrade to TLS                   May 2000


       HTTP/1.1 101 Switching Protocols
       Upgrade: TLS/1.0, HTTP/1.1
       Connection: Upgrade

   Note that the protocol tokens listed in the Upgrade header of a 101
   Switching Protocols response specify an ordered 'bottom-up' stack.

   As specified in  HTTP/1.1 [1], Section 10.1.2: "The server will
   switch protocols to those defined by the response's Upgrade header
   field immediately after the empty line which terminates the 101
   response".

   Once the TLS handshake completes successfully, the server MUST
   continue with the response to the original request. Any TLS handshake
   failure MUST lead to disconnection, per the TLS error alert
   specification.

4. Server Requested Upgrade to HTTP over TLS

   The Upgrade response header field advertises possible protocol
   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 Optional Advertisement

   As specified in HTTP/1.1 [1], the server MAY include an Upgrade
   header in any response other than 101 or 426 to indicate a
   willingness to switch to any (combination) of the protocols listed.

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
       Upgrade: TLS/1.0, HTTP/1.1
       Connection: Upgrade

   The server SHOULD include a message body in the 426 response which
   indicates in human readable form the reason for the error and
   describes any alternative courses which may be available to the user.

   Note that even if a client is willing to use TLS, it must use the
   operations in Section 3 to proceed; the TLS handshake cannot begin
   immediately after the 426 response.



Khare & Lawrence            Standards Track                     [Page 5]

RFC 2817                  HTTP Upgrade to TLS                   May 2000


5. Upgrade across Proxies

   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.

   Since TLS, in particular, requires end-to-end connectivity to provide
   authentication and prevent man-in-the-middle attacks, this memo
   specifies the CONNECT method to establish a tunnel across proxies.

   Once a tunnel is established, any of the operations in Section 3 can
   be used to establish a TLS connection.

5.1 Implications of Hop By Hop Upgrade

   If an origin server receives an Upgrade header from a proxy and
   responds with a 101 Switching Protocols response, it is changing the
   protocol only on the connection between the proxy and itself.
   Similarly, a proxy might return a 101 response to its client to
   change the protocol on that connection independently of the protocols
   it is using to communicate toward the origin server.

   These scenarios also complicate diagnosis of a 426 response.  Since
   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.

   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.

5.2 Requesting a Tunnel with CONNECT

   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:

      CONNECT server.example.com:80 HTTP/1.1
      Host: server.example.com:80




Khare & Lawrence            Standards Track                     [Page 6]

RFC 2817                  HTTP Upgrade to TLS                   May 2000


   Other HTTP mechanisms can be used normally with the CONNECT method --
   except end-to-end protocol Upgrade requests, of course, since the
   tunnel must be established first.

   For example, proxy authentication might be used to establish the
   authority to create a tunnel:

      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 (2xx) 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.