HTTP Over TLS
RFC 2818
Document | Type |
RFC - Informational
(May 2000; Errata)
Was draft-ietf-tls-https (tls WG)
|
|
---|---|---|---|
Author | Eric Rescorla | ||
Last updated | 2013-03-02 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 2818 (Informational) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group E. Rescorla Request for Comments: 2818 RTFM, Inc. Category: Informational May 2000 HTTP Over TLS Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This memo describes how to use TLS to secure HTTP connections over the Internet. Current practice is to layer HTTP over SSL (the predecessor to TLS), distinguishing secured traffic from insecure traffic by the use of a different server port. This document documents that practice using TLS. A companion document describes a method for using HTTP/TLS over the same port as normal HTTP [RFC2817]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Terminology . . . . . . . . . . . . . . . 2 2. HTTP Over TLS . . . . . . . . . . . . . . . . . . . . . . 2 2.1. Connection Initiation . . . . . . . . . . . . . . . . . 2 2.2. Connection Closure . . . . . . . . . . . . . . . . . . 2 2.2.1. Client Behavior . . . . . . . . . . . . . . . . . . . 3 2.2.2. Server Behavior . . . . . . . . . . . . . . . . . . . 3 2.3. Port Number . . . . . . . . . . . . . . . . . . . . . . 4 2.4. URI Format . . . . . . . . . . . . . . . . . . . . . . 4 3. Endpoint Identification . . . . . . . . . . . . . . . . . 4 3.1. Server Identity . . . . . . . . . . . . . . . . . . . . 4 3.2. Client Identity . . . . . . . . . . . . . . . . . . . . 5 References . . . . . . . . . . . . . . . . . . . . . . . . . 6 Security Considerations . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . 6 Full Copyright Statement . . . . . . . . . . . . . . . . . . 7 Rescorla Informational [Page 1] RFC 2818 HTTP Over TLS May 2000 1. Introduction HTTP [RFC2616] was originally used in the clear on the Internet. However, increased use of HTTP for sensitive applications has required security measures. SSL, and its successor TLS [RFC2246] were designed to provide channel-oriented security. This document describes how to use HTTP over TLS. 1.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 [RFC2119]. 2. HTTP Over TLS Conceptually, HTTP/TLS is very simple. Simply use HTTP over TLS precisely as you would use HTTP over TCP. 2.1. Connection Initiation The agent acting as the HTTP client should also act as the TLS client. It should initiate a connection to the server on the appropriate port and then send the TLS ClientHello to begin the TLS handshake. When the TLS handshake has finished. The client may then initiate the first HTTP request. All HTTP data MUST be sent as TLS "application data". Normal HTTP behavior, including retained connections should be followed. 2.2. Connection Closure TLS provides a facility for secure connection closure. When a valid closure alert is received, an implementation can be assured that no further data will be received on that connection. TLS implementations MUST initiate an exchange of closure alerts before closing a connection. A TLS implementation MAY, after sending a closure alert, close the connection without waiting for the peer to send its closure alert, generating an "incomplete close". Note that an implementation which does this MAY choose to reuse the session. This SHOULD only be done when the application knows (typically through detecting HTTP message boundaries) that it has received all the message data that it cares about. As specified in [RFC2246], any implementation which receives a connection close without first receiving a valid closure alert (a "premature close") MUST NOT reuse that session. Note that a premature close does not call into question the security of the data already received, but simply indicates that subsequent data might Rescorla Informational [Page 2] RFC 2818 HTTP Over TLS May 2000 have been truncated. Because TLS is oblivious to HTTP request/response boundaries, it is necessary to examine the HTTP data itself (specifically the Content-Length header) to determine whether the truncation occurred inside a message or between messages. 2.2.1. Client Behavior Because HTTP uses connection closure to signal end of server data, client implementations MUST treat any premature closes as errors andShow full document text