< draft-ietf-tls-https-02.txt   draft-ietf-tls-https-03.txt >
E. Rescorla
E. Rescorla
INTERNET-DRAFT RTFM, Inc. INTERNET-DRAFT RTFM, Inc.
<draft-ietf-tls-https-02.txt> September 1998 (Expires March-99) <draft-ietf-tls-https-03.txt> September 1999 (Expires March-00)
HTTP Over TLS HTTP Over TLS
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference mate-
material or to cite them other than as ``work in progress.'' rial or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast). ftp.isi.edu (US West Coast).
Abstract Abstract
This memo describes how to use TLS to secure HTTP connections over This memo describes how to use TLS to secure HTTP connections over
the Internet. Current practice is to layer HTTP over SSL (the prede- the Internet. Current practice is to layer HTTP over SSL (the prede-
cessor to TLS), distinguishing secured traffic from insecure traffic cessor to TLS), distinguishing secured traffic from insecure traffic
by the use of a different server port. This document documents that by the use of a different server port. This document documents that
practice using TLS. A companion document describes a method for using practice using TLS. A companion document describes a method for using
HTTP/TLS over the same port as normal HTTP. HTTP/TLS over the same port as normal HTTP.
1. Introduction 1. Introduction
HTTP [RFC2068] was originally used in the clear on the Internet. HTTP [RFC2616] was originally used in the clear on the Internet.
However, increased use of HTTP for sensitive applications has However, increased use of HTTP for sensitive applications has
required security measures. SSL, and its successor TLS [TLS] were required security measures. SSL, and its successor TLS [TLS] were
designed to provide channel-oriented security. This document designed to provide channel-oriented security. This document
describes how to use HTTP over TLS. describes how to use HTTP over TLS.
1.1. Discussion of this Draft 1.1. Discussion of this Draft
This draft is being discussed on the "ietf-apps-tls" mailing list. To This draft is being discussed on the "ietf-apps-tls" mailing list. To
subscribe, send a message to: subscribe, send a message to:
ietf-apps-tls-request@imc.org ietf-apps-tls-request@imc.org
with the single word
subscribe Internet-Draft HTTP Over TLS
in the body of the message. There is a Web site for the mailing list with the single word
at <http://www.imc.org/ietf-apps-tls/>.
subscribe
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 1.2. Requirements Terminology
Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
"MAY" that appear in this document are to be interpreted as described "MAY" that appear in this document are to be interpreted as described
in [RFC2119]. in [RFC2119].
2. HTTP Over TLS 2. HTTP Over TLS
Conceptually, HTTP/TLS is very simple. Simply use HTTP over TLS pre- Conceptually, HTTP/TLS is very simple. Simply use HTTP over TLS pre-
cisely as you would use HTTP over TCP. cisely as you would use HTTP over TCP.
2.1. Connection Initiation 2.1. Connection Initiation
The agent acting as the HTTP client should also act as the TLS The agent acting as the HTTP client should also act as the TLS
client. It should initiate a connection to the server on the client. It should initiate a connection to the server on the appro-
appropriate port and then send the TLS ClientHello to begin the TLS priate port and then send the TLS ClientHello to begin the TLS hand-
handshake. When the TLS handshake has finished. The client may then shake. When the TLS handshake has finished. The client may then ini-
initiate the first HTTP request. All HTTP data MUST be sentas TLS tiate the first HTTP request. All HTTP data MUST be sentas TLS
"application data". Normal HTTP behavior, including retained connec- "application data". Normal HTTP behavior, including retained connec-
tions should be followed. tions should be followed.
2.2. Connection Closure 2.2. Connection Closure
TLS provides a facility for secure connection closure. When a valid TLS provides a facility for secure connection closure. When a valid
closure alert is received, an implementation can be assured that no closure alert is received, an implementation can be assured that no
further data will be received on that connection. TLS implementa- further data will be received on that connection. TLS implementa-
tions MUST initiate an exchange of closure alerts before closing a tions MUST initiate an exchange of closure alerts before closing a
connection. A TLS implementation MAY, after sending a closure alert, connection. A TLS implementation MAY, after sending a closure alert,
close the connection without waiting for the peer to send its closure close the connection without waiting for the peer to send its closure
alert, generating an "incomplete close". Note that an implementation alert, generating an "incomplete close". Note that an implementation
which does this MAY choose to reuse the session. This SHOULD only be which does this MAY choose to reuse the session. This SHOULD only be
done when the application knows (typically through detecting HTTP done when the application knows (typically through detecting HTTP
message boundaries) that it has received all the message data that it message boundaries) that it has received all the message data that it
cares about. cares about.
As specified in [TLS], any implementation which receives a connection As specified in [TLS], any implementation which receives a connection
close without first receiving a valid closure alert (a "premature close without first receiving a valid closure alert (a "premature
close") MUST NOT reuse that session. Note that a premature close does close") MUST NOT reuse that session. Note that a premature close
not call into question the security of the data already received, but does not call into question the security of the data already
simply indicates that subsequent data might have been truncated. received, but simply indicates that subsequent data might have been
Because TLS is oblivious to HTTP request/response boundaries, it is truncated. Because TLS is oblivious to HTTP request/response
necessary to examine the HTTP data itself (specifically the Content-
Length header) to determine whether the truncation occurred inside a Internet-Draft HTTP Over TLS
message or between messages.
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.1. Client Behavior 2.2.1. Client Behavior
Because HTTP uses connection closure to signal end of server data, Because HTTP uses connection closure to signal end of server data,
client implementations MUST treat any premature closes as errors and client implementations MUST treat any premature closes as errors and
the data received as potentially truncated. Two cases in particular the data received as potentially truncated. Two cases in particular
deserve special note: deserve special note:
A HTTP response without a Content-Length header. Since data length in A HTTP response without a Content-Length header. Since data length in
this situation is signalled by connection close a premature close this situation is signalled by connection close a premature close
generated by the server cannot be distinguished from a spurious generated by the server cannot be distinguished from a spurious
close generated by an attacker. close generated by an attacker.
A HTTP response with a valid Content-Length header closed before 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 all data has been read. Because TLS does not provide document
impossible to determine whether the server has miscomputed the oriented protection, it is impossible to determine whether the
Content-Length or an attacker has truncated the connection. server has miscomputed the Content-Length or an attacker has
truncated the connection.
When encountering a premature close, a client SHOULD treat as com- When encountering a premature close, a client SHOULD treat as com-
pleted all requests for which it has received as much data as speci- pleted all requests for which it has received as much data as speci-
fied in the Content-Length header. fied in the Content-Length header.
A client detecting an incomplete close SHOULD recover gracefully. It A client detecting an incomplete close SHOULD recover gracefully. It
MAY resume a TLS session closed in this fashion. MAY resume a TLS session closed in this fashion.
Clients MUST send a closure alert before closing the connection. Clients MUST send a closure alert before closing the connection.
Clients which are unprepared to receive any more data MAY choose not 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- to wait for the server's closure alert and simply close the connec-
tion, thus generating an incomplete close on the server side. tion, thus generating an incomplete close on the server side.
2.2.2. Server Behavior 2.2.2. Server Behavior
RFC2068 permits an HTTP client to close the connection at any time, RFC2068 permits an HTTP client to close the connection at any time,
and requires servers to recover gracefully. In particular, servers and requires servers to recover gracefully. In particular, servers
SHOULD be prepared to receive an incomplete close from the client, SHOULD be prepared to receive an incomplete close from the client,
since the client can often determine when the end of server data is. since the client can often determine when the end of server data is.
Servers SHOULD be willing to resume TLS sessions closed in this Servers SHOULD be willing to resume TLS sessions closed in this fash-
fashion. 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
Internet-Draft HTTP Over TLS
Implementation note: In HTTP implementations which do not use per-
sistent connections, the server ordinarily expects to be able to sig-
nal 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. dropped the connection.
Servers MUST attempt to initiate an exchange of closure alerts with Servers MUST attempt to initiate an exchange of closure alerts with
the client before closing the connection. Servers MAY close the con- the client before closing the connection. Servers MAY close the con-
nection after sending the closure alert, thus generating an incom- nection after sending the closure alert, thus generating an incom-
plete close on the client side. plete close on the client side.
2.3. Port Number 2.3. Port Number
The first data that an HTTP server expects to receive from the client The first data that an HTTP server expects to receive from the client
skipping to change at line 168 skipping to change at page 4, line 32
443. This does not preclude HTTP/TLS from being run over another 443. This does not preclude HTTP/TLS from being run over another
transport. TLS only presumes a reliable connection-oriented data transport. TLS only presumes a reliable connection-oriented data
stream. stream.
2.4. URI Format 2.4. URI Format
HTTP/TLS is differentiated from HTTP URIs by using the 'https' proto- HTTP/TLS is differentiated from HTTP URIs by using the 'https' proto-
col identifier in place of the 'http' protocol identifier. An example col identifier in place of the 'http' protocol identifier. An example
URI specifying HTTP/TLS is: URI specifying HTTP/TLS is:
https://abc.com:80/~smith/home.html https://www.example.com/~smith/home.html
3. Endpoint Identification 3. Endpoint Identification
3.1. Server Identity 3.1. Server Identity
In general, HTTP/TLS requests are generated by dereferencing a URI. In general, HTTP/TLS requests are generated by dereferencing a URI.
As a consequence, the hostname for the server is known to the client. 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 If the hostname is available, the client MUST check it against the
server's identity as presented in the server's Certificate message, server's identity as presented in the server's Certificate message,
in order to prevent man-in-the-middle attacks. in order to prevent man-in-the-middle attacks.
skipping to change at line 190 skipping to change at page 5, line 5
If the client has external information as to the expected identity of If the client has external information as to the expected identity of
the server, the hostname check MAY be omitted. (For instance, a the server, the hostname check MAY be omitted. (For instance, a
client may be connecting to a machine whose address and hostname are client may be connecting to a machine whose address and hostname are
dynamic but the client knows the certificate that the server will dynamic but the client knows the certificate that the server will
present.) In such cases, it is important to narrow the scope of present.) In such cases, it is important to narrow the scope of
acceptable certificates as much as possible in order to prevent man acceptable certificates as much as possible in order to prevent man
in the middle attacks. In special cases, it may be appropriate for 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 the client to simply ignore the server's identity, but it must be
understood that this leaves the connection open to active attack. understood that this leaves the connection open to active attack.
Internet-Draft HTTP Over TLS
If a subjectAltName extension of type dNSName is present, that MUST If a subjectAltName extension of type dNSName is present, that MUST
be used as the identity. Otherwise, the (most specific) Common Name be used as the identity. Otherwise, the (most specific) Common Name
field in the Subject field of the certificate MUST be used. Although 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 the use of the Common Name is existing practice, it is deprecated and
Certification Authorities are encouraged to use the dNSName instead. Certification Authorities are encouraged to use the dNSName instead.
Matching is performed using the matching rules specified by [PKIX]. Matching is performed using the matching rules specified by [PKIX].
If more than one identity of a given type is present in the certifi- If more than one identity of a given type is present in the certifi-
cate (e.g. more than one dNSName name, a match in any one of the set cate (e.g. more than one dNSName name, a match in any one of the set
is considered acceptable.) Names may contain the wildcard character * is considered acceptable.) Names may contain the wildcard character *
skipping to change at line 216 skipping to change at page 5, line 33
user the opportunity to continue with the connection in any case) or user the opportunity to continue with the connection in any case) or
terminate the connection with a bad certificate error. Automated terminate the connection with a bad certificate error. Automated
clients MUST log the error to an appropriate audit log (if available) clients MUST log the error to an appropriate audit log (if available)
and SHOULD terminate the connection (with a bad certificate error). and SHOULD terminate the connection (with a bad certificate error).
Automated clients MAY provide a configuration setting that disables Automated clients MAY provide a configuration setting that disables
this check, but MUST provide a setting which enables it. this check, but MUST provide a setting which enables it.
Note that in many cases the URI itself comes from an untrusted Note that in many cases the URI itself comes from an untrusted
source. The above-described check provides no protection against source. The above-described check provides no protection against
attacks where this source is compromised. For example, if the URI was attacks where this source is compromised. For example, if the URI was
obtained by clicking on an HTML page which was itself obtained obtained by clicking on an HTML page which was itself obtained with-
without using HTTP/TLS, a man in the middle could have replaced the out using HTTP/TLS, a man in the middle could have replaced the URI.
URI. In order to prevent this form of attack, users should carefully In order to prevent this form of attack, users should carefully exam-
examine the certificate presented by the server to determine if it ine the certificate presented by the server to determine if it meets
meets their expectations. their expectations.
3.2. Client Identity 3.2. Client Identity
Typically, the server has no external knowledge of what the client's 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 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 certificate chain rooted in an appropriate CA) are not possible. If a
server has such knowledge (typically from some source external to server has such knowledge (typically from some source external to
HTTP or TLS) it SHOULD check the identity as described above. HTTP or TLS) it SHOULD check the identity as described above.
Internet-Draft HTTP Over TLS
References References
[PKIX] R. Housley, W. Ford, W. Polk, D. Solo, Internet Public Key [PKIX] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
Infrastructure: Part I: X.509 Certificate and CRL Profile, Public Key Infrastructure: Part I: X.509 Certificate and CRL
<draft-ietf-pkix-ipki-part1-06.txt>, October 1997. Profile", RFC 2459, January 1999.
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC-2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Berners-Lee, T., "Hypertext Transfer Protocol -- HTTP/1.1" Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
RFC 2068, January 1997. Transfer Protocol, HTTP/1.1" RFC 2616, June 1999.
[RFC2119] Bradner, S., "Key Words for use in RFCs to indicate [RFC2119] Bradner, S., "Key Words for use in RFCs to indicate
Requirement Levels", RFC2119, March 1997. Requirement Levels", RFC2119, March 1997.
[TLS] Dierks, T., Allen, C., "The TLS Protocol", RFC2246, January 1999. [TLS] Dierks, T., Allen, C., "The TLS Protocol", RFC2246, January 1999.
Security Considerations Security Considerations
This entire document is about security. This entire document is about security.
Author's Address Author's Address
Eric Rescorla <ekr@rtfm.com> Eric Rescorla <ekr@rtfm.com>
RTFM, Inc. RTFM, Inc.
30 Newell Road, #16 30 Newell Road, #16
East Palo Alto, CA 94303 East Palo Alto, CA 94303
Phone: (650) 328-8631 Phone: (650) 328-8631
Table of Contents
1. Introduction ................................................... 1
1.1. Discussion of this Draft ..................................... 1
1.2. 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 Internet-Draft HTTP Over TLS
Security Considerations ........................................... 6 Table of Contents
Author's Address .................................................. 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1. Discussion of this Draft . . . . . . . . . . . . . . . . . . . 1
1.2. 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
 End of changes. 26 change blocks. 
79 lines changed or deleted 72 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/