rfc2818.txt

RFC 的详细文档！

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 and
   the data received as potentially truncated.  While in some cases the
   HTTP protocol allows the client to find out whether truncation took
   place so that, if it received the complete reply, it may tolerate
   such errors following the principle to "[be] strict when sending and
   tolerant when receiving" [RFC1958], often truncation does not show in
   the HTTP protocol data; two cases in particular deserve special note:

     A HTTP response without a Content-Length header. Since data length
     in this situation is signalled by connection close a premature
     close generated by the server cannot be distinguished from a
     spurious close generated by an attacker.

     A HTTP response with a valid Content-Length header closed before
     all data has been read. Because TLS does not provide document
     oriented protection, it is impossible to determine whether the
     server has miscomputed the Content-Length or an attacker has
     truncated the connection.

   There is one exception to the above rule. When encountering a
   premature close, a client SHOULD treat as completed all requests for
   which it has received as much data as specified in the Content-Length
   header.

   A client detecting an incomplete close SHOULD recover gracefully.  It
   MAY resume a TLS session closed in this fashion.

   Clients MUST send a closure alert before closing the connection.
   Clients which are unprepared to receive any more data MAY choose not
   to wait for the server's closure alert and simply close the
   connection, thus generating an incomplete close on the server side.

2.2.2.  Server Behavior

   RFC 2616 permits an HTTP client to close the connection at any time,
   and requires servers to recover gracefully.  In particular, servers
   SHOULD be prepared to receive an incomplete close from the client,
   since the client can often determine when the end of server data is.
   Servers SHOULD be willing to resume TLS sessions closed in this
   fashion.



Rescorla                     Informational                      [Page 3]

RFC 2818                     HTTP Over TLS                      May 2000


   Implementation note: In HTTP implementations which do not use
   persistent connections, the server ordinarily expects to be able to
   signal end of data by closing the connection. When Content-Length is
   used, however, the client may have already sent the closure alert and
   dropped the connection.

   Servers MUST attempt to initiate an exchange of closure alerts with
   the client before closing the connection. Servers MAY close the
   connection after sending the closure alert, thus generating an
   incomplete close on the client side.

2.3.  Port Number

   The first data that an HTTP server expects to receive from the client
   is the Request-Line production. The first data that a TLS server (and
   hence an HTTP/TLS server) expects to receive is the ClientHello.
   Consequently, common practice has been to run HTTP/TLS over a
   separate port in order to distinguish which protocol is being used.
   When HTTP/TLS is being run over a TCP/IP connection, the default port
   is 443. This does not preclude HTTP/TLS from being run over another
   transport. TLS only presumes a reliable connection-oriented data
   stream.

2.4.  URI Format