HTTP Proxy protocol (http connect)

Abstract

 

  This memo explains how to usethe upgrade mechanic in HTTP/1.1
    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
    Https: at 443). It alsoenables "virtual hosting", so a single HTTP +
    TLS server can disambiguatetraffic intended for several hostnames
    A single IP address.

  Since HTTP/1.1 [1] definesupgrade as a hop-by-hop mechanic, this
  Memo also documents the httpconnect method for establishing end--
  End tunnels upload SS 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
  Secured and unsecured use ofother application protocols (e.g.
  Snews, ftps). This approacheffectively halves the number
  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 numbersshoshould be deprecated. The HTTP/1.1
  Upgrade mechanic can applytransport layer security [6] to an open
  HTTP connection.

  In the nearly two years since, there has been broad acceptance of
  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
  Internet Printing Protocol [7], call for just such a mechanic in
  Order to move ahead in theietf standards process.

  The upgrade mechanic alsosolves the "virtual hosting" problem.
  Rather than allocatingmultiple IP addresses to a single host,
  HTTP/1.1 server will use thehost: header to disambiguate
  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
  Certificates based on Theinitial HOST: Header -- will allow ISPs
  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
  Mechanic (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 4 describe the operation of a directly
  Connected client and server. Intermediate proxies must establish
  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
  Complete the current HTTP/1.1 request 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 wocould 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 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
  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
  Tokens of the Protocol stackit is switching:

      HTTP/1.1 101 switching protocols
      Upgrade: TLS/1.0, HTTP/1.1
      Connection: Upgrade

  Notes that the Protocol tokenslisted in the upgrade header of A 101
  Switching protocols responsespecify an ordered 'bottom-up' stack.

  As specifiedinHTTP/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