WDIFF

draft-ietf-tls-https-03.txt --> rfc2818.txt

Network Working Group E. Rescorla
INTERNET-DRAFT
Request for Comments: 2818 RTFM, Inc.
<draft-ietf-tls-https-03.txt> September 1999 (Expires March-00)
Category: Informational May 2000

HTTP Over TLS

Status of this Memo

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of memo provides information for the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum community. It does
not specify an Internet standard of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference mate-
rial or to cite them other than as ``work in progress.''

The list kind. Distribution of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt this
memo is unlimited.

To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast). 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 prede-
cessor
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.

1. Introduction HTTP [RFC2616] was originally used in the clear on the Internet.
However, increased use
[RFC2817].

Table of HTTP for sensitive applications has
required security measures. SSL, and its successor TLS [TLS] were
designed to provide channel-oriented security. This document
describes how to use HTTP over TLS. Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Discussion of this Draft

This draft is being discussed on the "ietf-apps-tls" mailing list. To
subscribe, send a message to:

ietf-apps-tls-request@imc.org

Rescorla [Page 1]
Internet-Draft HTTP Over TLS

with the single word

in the body of the message. There is a Web site for the mailing list at
<http://www.imc.org/ietf-apps-tls/>.

1.2. 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
2. HTTP Over TLS

Conceptually, HTTP/TLS is very simple. Simply use HTTP over TLS pre-
cisely 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 appro-
priate port and then send the TLS ClientHello to begin the TLS hand-
shake. When the TLS handshake has finished. The client may then ini-
tiate the first HTTP request. All HTTP data MUST be sentas TLS
"application data". Normal HTTP behavior, including retained connec-
tions should be followed. . . . . . . . . . . . . . . . . . . . . . . 2
2.1. Connection Initiation . . . . . . . . . . . . . . . . . 2
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 implementa-
tions 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 [TLS], 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 have been
truncated. Because TLS is oblivious to HTTP request/response

Rescorla [Page 2]
Internet-Draft HTTP Over TLS

boundaries, it is necessary to examine the HTTP data itself (specifi-
cally the Content-Length header) to determine whether the truncation
occurred inside a message or between messages. . . . . . . . . . . . . . . . . . . 2
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. 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.

When encountering a premature close, a client SHOULD treat as com-
pleted all requests for which it has received as much data as speci-
fied 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 connec-
tion, thus generating an incomplete close on the server side.

2.2.2. Server Behavior

RFC2068 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 fash-
ion.

Implementation note: In HTTP implementations which do not use persis-
tent 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

Rescorla [Page 3]
Internet-Draft HTTP Over TLS

dropped the connection.

Servers MUST attempt to initiate an exchange of closure alerts with
the client before closing the connection. Servers MAY close the con-
nection after sending the closure alert, thus generating an incom-
plete close on the client side. . . . . . . . . . . . . . . . . . . . 3
2.2.2. Server Behavior . . . . . . . . . . . . . . . . . . . 3
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. Con-
sequently, 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. . . . . . . . . . . . . . . . . . . . . . . 4
2.4. URI Format

HTTP/TLS is differentiated from HTTP URIs by using the 'https' proto-
col identifier in place of the 'http' protocol identifier. An example
URI specifying HTTP/TLS is:

https://www.example.com/~smith/home.html . . . . . . . . . . . . . . . . . . . . . . 4
3. Endpoint Identification . . . . . . . . . . . . . . . . . 4
3.1. Server Identity

In general, HTTP/TLS requests are generated by dereferencing a URI.
As a consequence, the hostname for the server is known to the client.
If the hostname is available, the client MUST check it against the
server's identity as presented in the server's Certificate message,
in order to prevent man-in-the-middle attacks.

If the client has external information as to the expected identity of
the server, the hostname check MAY be omitted. (For instance, a
client may be connecting to a machine whose address and hostname are
dynamic but the client knows the certificate that the server will
present.) In such cases, it is important to narrow the scope of
acceptable certificates as much as possible in order to prevent man
in the middle attacks. In special cases, it may be appropriate for
the client to simply ignore the server's identity, but it must be
understood that this leaves the connection open to active attack.

Rescorla [Page 4]
Internet-Draft . . . . . . . . . . . . . . . . . . . . 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

If a subjectAltName extension of type dNSName is present, that MUST
be May 2000

1. Introduction

HTTP [RFC2616] was originally used as the identity. Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used. Although clear on the Internet.
However, increased use of the Common Name is existing practice, it is deprecated HTTP for sensitive applications has
required security measures. SSL, and
Certification Authorities are encouraged its successor TLS [RFC2246] were
designed to provide channel-oriented security. This document
describes how to use the dNSName instead.

Matching 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 performed using very simple. Simply use HTTP over TLS
precisely as you would use HTTP over TCP.

2.1. Connection Initiation

The agent acting as the matching rules specified by [PKIX].
If more than one identity of a given type is present in HTTP client should also act as the certifi-
cate (e.g. more than one dNSName name, TLS
client. It should initiate a match in any one of the set
is considered acceptable.) Names may contain the wildcard character *
which is considered connection to match any single domain name component or com-
ponent fragment. E.g. *.a.com matches foo.a.com but not
bar.foo.a.com. f*.com matches foo.com but not bar.com.

If the hostname does not match the identity in the certificate, user
oriented clients MUST either notify the user (clients MAY give server on the
user
appropriate port and then send the opportunity TLS ClientHello to continue with the connection in any case) or
terminate begin the connection with a bad certificate error. Automated
clients MUST log TLS
handshake. When the error to an appropriate audit log (if available)
and SHOULD terminate TLS handshake has finished. The client may then
initiate the connection (with 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 bad certificate error).
Automated clients MAY provide facility for secure connection closure. When a configuration setting valid
closure alert is received, an implementation can be assured that disables
this check, but MUST provide a setting which enables it.

Note no
further data will be received on that in many cases the URI itself comes from connection. TLS
implementations MUST initiate an untrusted
source. The above-described check provides no protection against
attacks where this source is compromised. For example, if the URI was
obtained by clicking on an HTML page which was itself obtained with-
out using HTTP/TLS, exchange of closure alerts before
closing a man in connection. A TLS implementation MAY, after sending a
closure alert, close the middle could have replaced connection without waiting for the URI.
In order peer to prevent
send its closure alert, generating an "incomplete close". Note that
an implementation which does this form of attack, users should carefully exam-
ine MAY choose to reuse the certificate presented by session.
This SHOULD only be done when the server to determine if application knows (typically
through detecting HTTP message boundaries) that it meets
their expectations.

3.2. Client Identity

Typically, the server has no external knowledge of what received all
the client's
identity ought to be and so checks (other than message data that the client has a
certificate chain rooted it cares about.

As specified in an appropriate CA) are not possible. If [RFC2246], any implementation which receives a
server has such knowledge (typically from some source external to
HTTP or TLS) it SHOULD check
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 identity as described above. security of the data
already received, but simply indicates that subsequent data might

Rescorla Informational [Page 5]
Internet-Draft 2]

RFC 2818 HTTP Over TLS

References
[PKIX] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
Public Key Infrastructure: Part I: X.509 Certificate and CRL
Profile", RFC 2459, January 1999.

[RFC-2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P. 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 T. Berners-Lee, "Hypertext
Transfer Protocol, HTTP/1.1" RFC 2616, June 1999.

[RFC2119] Bradner, S., "Key Words for use
the data received as potentially truncated. While in RFCs some cases the
HTTP protocol allows the client to indicate
Requirement Levels", RFC2119, March 1997.

[TLS] Dierks, T., Allen, C., "The TLS Protocol", RFC2246, January 1999.

Security Considerations

This entire document 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 about security.

Author's Address

Eric Rescorla <ekr@rtfm.com>
RTFM, Inc.
30 Newell Road, #16
East Palo Alto, CA 94303
Phone: (650) 328-8631

Rescorla [Page 6]
Internet-Draft signalled by connection close a premature
close generated by the server cannot be distinguished from a
spurious close generated by an attacker.

A HTTP Over response with a valid Content-Length header closed before
all data has been read. Because TLS

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1. Discussion of this Draft . . . . . . . . . . . . . . . . . . . 1
1.2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 2
2. 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1. Connection Initiation . . . . . . . . . . . . . . . . . . . . . 2
2.2. Connection Closure . . . . . . . . . . . . . . . . . . . . . . 2
2.2.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 3
2.2.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4. URI Format . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Endpoint Identification . . . . . . . . . . . . . . . . . . . . . 4

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

HTTP/TLS is differentiated from HTTP URIs by using the 'https'
protocol identifier in place of the 'http' protocol identifier. An
example URI specifying HTTP/TLS is:

https://www.example.com/~smith/home.html

3. Endpoint Identification

3.1. Server Identity . . . . . . . . . . . . . . . . . . . . . . . . 4

Rescorla Informational [Page 4]

RFC 2818 HTTP Over TLS May 2000

in the middle attacks. In special cases, it may be appropriate for
the client to simply ignore the server's identity, but it must be
understood that this leaves the connection open to active attack.

If a subjectAltName extension of type dNSName is present, that MUST
be used as the identity. Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used. Although
the use of the Common Name is existing practice, it is deprecated and
Certification Authorities are encouraged to use the dNSName instead.

Matching is performed using the matching rules specified by
[RFC2459]. If more than one identity of a given type is present in
the certificate (e.g., more than one dNSName name, a match in any one
of the set is considered acceptable.) Names may contain the wildcard
character * which is considered to match any single domain name
component or component fragment. E.g., *.a.com matches foo.a.com but
not bar.foo.a.com. f*.com matches foo.com but not bar.com.

In some cases, the URI is specified as an IP address rather than a
hostname. In this case, the iPAddress subjectAltName must be present
in the certificate and must exactly match the IP in the URI.

If the hostname does not match the identity in the certificate, user
oriented clients MUST either notify the user (clients MAY give the
user the opportunity to continue with the connection in any case) or
terminate the connection with a bad certificate error. Automated
clients MUST log the error to an appropriate audit log (if available)
and SHOULD terminate the connection (with a bad certificate error).
Automated clients MAY provide a configuration setting that disables
this check, but MUST provide a setting which enables it.

Note that in many cases the URI itself comes from an untrusted
source. The above-described check provides no protection against
attacks where this source is compromised. For example, if the URI was
obtained by clicking on an HTML page which was itself obtained
without using HTTP/TLS, a man in the middle could have replaced the
URI. In order to prevent this form of attack, users should carefully
examine the certificate presented by the server to determine if it
meets their expectations.

3.2. Client Identity . . . . . . . . . . . . . . . . . . . . . . . . 5

Typically, the server has no external knowledge of what the client's
identity ought to be and so checks (other than that the client has a
certificate chain rooted in an appropriate CA) are not possible. If a
server has such knowledge (typically from some source external to
HTTP or TLS) it SHOULD check the identity as described above.

Rescorla Informational [Page 5]

RFC 2818 HTTP Over TLS May 2000

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

[RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
Public Key Infrastructure: Part I: X.509 Certificate and
CRL Profile", RFC 2459, January 1999.

[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,
L., Leach, P. and T. Berners-Lee, "Hypertext Transfer
Protocol, HTTP/1.1", RFC 2616, June 1999.

[RFC2119] Bradner, S., "Key Words for use in RFCs to indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246,
January 1999.

[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
HTTP/1.1", RFC 2817, May 2000.

Security Considerations . . . . . . . . . . . . . . . . . . . . . . 6

This entire document is about security.

Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Eric Rescorla
RTFM, Inc.
30 Newell Road, #16
East Palo Alto, CA 94303

Phone: (650) 328-8631
EMail: ekr@rtfm.com

Rescorla Informational [Page 6]

RFC 2818 HTTP Over TLS May 2000

Full Copyright Statement

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Funding for the RFC Editor function is currently provided by the
Internet Society.

Rescorla Informational [Page 7]

----