Upgrading to TLS Within HTTP/1.1
RFC 2817
Document | Type |
RFC - Proposed Standard
(May 2000; Errata)
Updates RFC 2616
|
|
---|---|---|---|
Authors | Rohit Khare , Scott Lawrence | ||
Last updated | 2020-01-21 | ||
Stream | Internet Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized with errata bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 2817 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
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). Khare & Lawrence Standards Track [Page 1] 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 [Page 2] 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 implementingShow full document text