RFC 2817 (rfc2817) - Page 2 of 13

Upgrading to TLS Within HTTP/1

Alternative Format: Original Text Document

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
< Previous
Next >