RFC 2818 (rfc2818) - Page 2 of 7

HTTP Over TLS

RFC 2818                     HTTP Over TLS                      May 2000


1.  Introduction

   HTTP [RFC 2616] 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 [RFC 2246] 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 [RFC 2119].

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 [RFC 2246], 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