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.







 
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.








 
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).