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












 
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