HTTP代理协议(HTTP CONNECT)

Abstract

 

   This memo explains how to usethe Upgrade mechanism in HTTP/1.1 to
     initiate Transport LayerSecurity (TLS) over an existing TCP
     connection. This allowsunsecured and secured HTTP traffic to share
     the same well known port (inthis case, http: at 80 rather than
     https: at 443). It alsoenables "virtual hosting", so a single HTTP +
     TLS server can disambiguatetraffic intended for several hostnames at
     a single IP address.

     Since HTTP/1.1 [1] definesUpgrade as a hop-by-hop mechanism, this
     memo also documents the HTTPCONNECT method for establishing end-to-
     end tunnels across HTTPproxies. Finally, this memo establishes new
     IANA registries for publicHTTP status codes, as well as public or
     private Upgrade producttokens.

     This memo does NOT affect thecurrent definition of the 'https' URI
     scheme, which already definesa separate namespace
     (http://example.org/ andhttps://example.org/ are not equivalent).

1. Motivation
     The historical practice ofdeploying HTTP over SSL3 [3] has
     distinguished the combinationfrom HTTP alone by a unique URI scheme
     and the TCP port number. Thescheme '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 somecases, granted -- to distinguish between
     secured and unsecured use ofother application protocols (e.g.
     snews, ftps). This approacheffectively halves the number of
     available well knownports.

     At the Washington DC IETFmeeting in December 1997, the Applications
     Area Directors and the IESGreaffirmed that the practice of issuing
     parallel "secure" port numbersshould be deprecated. The HTTP/1.1
     Upgrade mechanism can applyTransport Layer Security [6] to an open
     HTTP connection.

     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 forgeneric Web browsing. In fact, nothing
     in this memo affects thecurrent interpretation of https: URIs.
     However, new applicationprotocols built atop HTTP, such as the
     Internet Printing Protocol[7], call for just such a mechanism in
     order to move ahead in theIETF standards process.

     The Upgrade mechanism alsosolves the "virtual hosting" problem.
     Rather than allocatingmultiple IP addresses to a single host, an
     HTTP/1.1 server will use theHost: header to disambiguate the
     intended web service. AsHTTP/1.1 usage has grown more prevalent,
     more ISPs are offeringname-based virtual hosting, thus delaying IP
     address spaceexhaustion.

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

2. Introduction

     TLS, a.k.a., SSL (SecureSockets Layer), establishes a private end-
     to-end connection, optionallyincluding strong mutual authentication,
     using a variety ofcryptosystems. Initially, a handshake phase uses
     three subprotocols to set up arecord layer, authenticate endpoints,
     set parameters, as well asreport errors.   Then, there is an ongoing
     layered record protocol thathandles encryption, compression, and
     reassembly for the remainderof the connection. The latter is
     intended to be completelytransparent. For example, there is no
     dependency between TLS'srecord markers and or certificates and
     HTTP/1.1's chunked encoding orauthentication.

     Either the client or servercan use the HTTP/1.1 [1] Upgrade
     mechanism (Section 14.42) toindicate that a TLS-secured connection
     is desired or necessary. Thismemo defines the "TLS/1.0" Upgrade
     token, and a new HTTP StatusCode, "426 Upgrade Required".

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

3. Client Requested Upgrade to HTTP over TLS

     When the client sends anHTTP/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.1request after switching to TLS/1.0.

3.1 Optional Upgrade

     A client MAY offer to switchto secured operation during any clear
     HTTP request when an unsecuredresponse would be acceptable:

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

     In this case, the server MAYrespond to the clear HTTP operation
     normally, OR switch to securedoperation (as detailed in the next
     section).

     Note that HTTP/1.1 [1]specifies "the upgrade keyword MUST be
     supplied within a Connectionheader field (section 14.10) whenever
     Upgrade is present in anHTTP/1.1 message".

3.2 Mandatory Upgrade

     If an unsecured response wouldbe unacceptable, a client MUST send an
     OPTIONS request first tocomplete 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 MUSTsend the intermediate "101 Switching
     Protocol" and MUST include anUpgrade response header specifying the
     tokens of the protocol stackit is switching to:

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

     Note that the protocol tokenslisted in the Upgrade header of a 101
     Switching Protocols responsespecify an ordered 'bottom-up' stack.

     As specifiedin   HTTP/1.1 [1], Section 10.1.2: "The serverwill
     switch protocols to thosedefined by the response's Upgrade header
     field immediately after theempty line which terminates the 101
     response".

     Once the TLS handshakecompletes successfully, the server MUST
     continue with the response tothe original request. Any TLS handshake
     failure MUST lead todisconnection, per the TLS error alert
     specification.

4. Server Requested Upgrade to HTTP over TLS

     The Upgrade response headerfield advertises possible protocol
     upgrades a server MAY accept.In conjunction with the "426 Upgrade
     Required" status code, aserver can advertise the exact protocol
     upgrade(s) that a client MUSTaccept 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 otherthan 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 aclient request can not be completed
     without TLS using the "426Upgrade Required" status code, which MUST
     include an an Upgrade headerfield 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 amessage body in the 426 response which
     indicates in human readableform the reason for the error and
     describes any alternativecourses which may be available to the user.

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

5. Upgrade across Proxies

     As a hop-by-hop header,Upgrade is negotiated between each pair of
     HTTPcounterparties.   If a User Agent sends a requestwith an Upgrade
     header to a proxy, it isrequesting a change to the protocol between
     itself and the proxy, not anend-to-end change.

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

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

5.1 Implications of Hop By Hop Upgrade
     If an origin server receivesan Upgrade header from a proxy and
     responds with a 101 SwitchingProtocols response, it is changing the
     protocol only on theconnection between the proxy and itself.
     Similarly, a proxy mightreturn a 101 response to its client to
     change the protocol on thatconnection independently of the protocols
     it is using to communicatetoward the origin server.

     These scenarios alsocomplicate diagnosis of a 426 response.  Since
     Upgrade is a hop-by-hopheader, a proxy that does not recognize 426
     might remove the accompanyingUpgrade header and prevent the client
     from determining the requiredprotocol switch.   If a client receives
     a 426 status without anaccompanying Upgrade header, it will need to
     request an end to end tunnelconnection as described in Section 5.2
     and repeat the request inorder to obtain the required upgrade
     information.

     This hop-by-hop definition ofUpgrade was a deliberate choice.   It
     allows for incrementaldeployment on either side of proxies, and for
     optimized protocols betweencascaded proxies without the knowledge of
     the parties that are not apart of the change.

5.2 Requesting a Tunnel with CONNECT
     A CONNECT method requests thata proxy establish a tunnel connection
     on its behalf. The Request-URIportion of the Request-Line is always
     an 'authority' as defined byURI Generic Syntax [2], which is to say
     the host name and port numberdestination of the requested connection
     separated by a colon:

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

     Other HTTP mechanisms can beused normally with the CONNECT method --
     except end-to-end protocolUpgrade requests, of course, since the
     tunnel must be establishedfirst.

     For example, proxyauthentication might be used to establish the
     authority to create atunnel:

          CONNECT server.example.com:80 HTTP/1.1
          Host: server.example.com:80
          Proxy-Authorization: basic aGVsbG86d29ybGQ=

     Like any other pipelinedHTTP/1.1 request, data to be tunneled may be
     sent immediately after theblank line. The usual caveats also apply:
     data may be discarded if theeventual response is negative, and the
     connection may be reset withno response if more than one TCP segment
     is outstanding.

5.3 Establishing a Tunnel with CONNECT

     Any successful (2xx) responseto a CONNECT request indicates that the
     proxy has established aconnection to the requested host and port,
     and has switched to tunnelingthe current connection to that server
     connection.

     It may be the case that theproxy itself can only reach the requested
     origin server through anotherproxy.   In this case, the first proxy
     SHOULD make a CONNECT requestof that next proxy, requesting a tunnel
     to theauthority.   A proxy MUST NOT respond with any 2xxstatus code
     unless it has either a director tunnel connection established to the
     authority.

     An origin server whichreceives a CONNECT request for itself MAY
     respond with a 2xx status codeto indicate that a connection is
     established.

     If at any point either one ofthe peers gets disconnected, any
     outstanding data that camefrom that peer will be passed to the other
     one, and after that also theother connection will be terminated by
     the proxy. If there isoutstanding data to that peer undelivered,
     that data will bediscarded.

6. Rationale for the use of a 4xx (client error) Status Code
     Reliable, interoperablenegotiation of Upgrade features requires an
     unambiguous failure signal.The 426 Upgrade Required status code
     allows a server todefinitively state the precise protocol extensions
     a given resource must beserved with.

     It might at first appear thatthe response should have been some form
     of redirection (a 3xx code),by analogy to an old-style redirection
     to an https:URI.   User agents that do not understandUpgrade:
     preclude this.

     Suppose that a 3xx code hadbeen assigned for "Upgrade Required"; a
     user agent that did notrecognize it would treat it as 300.   Itwould
     then properly look for a"Location" header in the response and
     attempt to repeat the requestat the URL in that header field. Since
     it did not know to Upgrade toincorporate the TLS layer, it would at
     best fail again at the newURL.

7.1 HTTP Status Code Registry
     The HTTP Status Code Registrydefines the name space for the Status-
     Code token in the Status lineof an HTTP response.   The initial
     values for this name space arethose specified by:

     1.   DraftStandard for HTTP/1.1 [1]
     2.   WebDistributed Authoring and Versioning [4] [defines 420-424]
     3.   WebDAVAdvanced Collections [5] (Work in Progress) [defines 425]
     4.   Section 6[defines 426]

     Values to be added to thisname space SHOULD be subject to review in
     the form of a standards trackdocument within the IETF Applications
     Area.   Anysuch document SHOULD be traceable through statuses of
     either 'Obsoletes' or'Updates' to the Draft Standard for
     HTTP/1.1 [1].

7.2 HTTP Upgrade Token Registry
     The HTTP Upgrade TokenRegistry defines the name space for product
     tokens used to identifyprotocols in the Upgrade HTTP header field.
     Each registered token shouldbe associated with one or a set of
     specifications, and withcontact information.

     The Draft Standard forHTTP/1.1 [1] specifies that these tokens obey
     the production for'product':
          product                = token ["/" product-version]
          product-version = token
     Registrations should beallowed on a First Come First Served basis as
     described in BCP 26 [10].These specifications need not be IETF
     documents or be subject toIESG review, but should obey the following
     rules:

     1.   A token,once registered, stays registered forever.
     2.   Theregistration MUST name a responsible party for the
            registration.
     3.   Theregistration MUST name a point of contact.
     4.   Theregistration MAY name the documentation required for the
            token.
     5.   Theresponsible party MAY change the registration at any time.
            The IANA will keep a record of all such changes, and makethem
            available upon request.
     6.   Theresponsible party for the first registration of a "product"
            token MUST approve later registrations of a "version" token
            together with that "product" token before they can beregistered.
     7.   Ifabsolutely required, the IESG MAY reassign the responsibility
            for a token. This will normally only be used in the case whena
            responsible party cannot be contacted.

     This specification defines theprotocol token "TLS/1.0" as the
     identifier for the protocolspecified by The TLS Protocol [6].

     It is NOT required thatspecifications for upgrade tokens be made
     publicly available, but thecontact information for the registration
     SHOULD be.