< draft-ietf-tls-https-01.txt   draft-ietf-tls-https-02.txt >
E. Rescorla E. Rescorla
INTERNET-DRAFT Terisa Systems, Inc. INTERNET-DRAFT RTFM, Inc.
<draft-ietf-tls-https-01.txt> March 1998 (Expires September-98) <draft-ietf-tls-https-02.txt> September 1998 (Expires March-99)
HTTP Over TLS HTTP Over TLS
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working 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 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
material or to cite them other than as ``work in progress.'' material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
skipping to change at line 72 skipping to change at line 73
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
appropriate port and then send the TLS ClientHello to begin the TLS appropriate port and then send the TLS ClientHello to begin the TLS
handshake. When the TLS handshake has finished. The client may then handshake. When the TLS handshake has finished. The client may then
initiate the first HTTP request. All HTTP data MUST be sent using as initiate the first HTTP request. All HTTP data MUST be sentas TLS
TLS "application data". Normal HTTP behavior, including retained "application data". Normal HTTP behavior, including retained connec-
connections 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
skipping to change at line 185 skipping to change at line 186
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.
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 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 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].
including wildcard matches. E.g. *.bar.com would match a.bar.com, If more than one identity of a given type is present in the certifi-
b.bar.com, etc. but not bar.com. If more than one identity of a given cate (e.g. more than one dNSName name, a match in any one of the set
type is present in the certificate (e.g. more than one dNSName name, is considered acceptable.) Names may contain the wildcard character *
a match in any one of the set is considered acceptable.) which is considered 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 If the hostname does not match the identity in the certificate, user
oriented clients MUST either notify the user (clients MAY give the oriented clients MUST either notify the user (clients MAY give the
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 close the connection, returning a bad certificate error. 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 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.
References References
skipping to change at line 225 skipping to change at line 242
Infrastructure: Part I: X.509 Certificate and CRL Profile, Infrastructure: Part I: X.509 Certificate and CRL Profile,
<draft-ietf-pkix-ipki-part1-06.txt>, October 1997. <draft-ietf-pkix-ipki-part1-06.txt>, October 1997.
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Berners-Lee, T., "Hypertext Transfer Protocol -- HTTP/1.1" Berners-Lee, T., "Hypertext Transfer Protocol -- HTTP/1.1"
RFC 2068, January 1997. RFC 2068, January 1997.
[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", RFCXXXX, November 1997. [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@terisa.com> Eric Rescorla <ekr@rtfm.com>
Terisa Systems, Inc. RTFM, Inc.
4984 El Camino Real 30 Newell Road, #16
Los Altos, CA 94022 East Palo Alto, CA 94303
Phone: (650) 919-1753 Phone: (650) 328-8631
Table of Contents Table of Contents
1. Introduction ................................................... 1 1. Introduction ................................................... 1
1.1. Discussion of this Draft ..................................... 1 1.1. Discussion of this Draft ..................................... 1
1.2. Requirements Terminology ..................................... 2 1.2. Requirements Terminology ..................................... 2
2. HTTP Over TLS .................................................. 2 2. HTTP Over TLS .................................................. 2
skipping to change at line 264 skipping to change at line 281
2.2.2. Server Behavior ............................................ 3 2.2.2. Server Behavior ............................................ 3
2.3. Port Number .................................................. 4 2.3. Port Number .................................................. 4
2.4. URI Format ................................................... 4 2.4. URI Format ................................................... 4
3. Endpoint Identification ........................................ 4 3. Endpoint Identification ........................................ 4
3.1. Server Identity .............................................. 4 3.1. Server Identity .............................................. 4
RN Client Identity ................................................ 5 3.2. Client Identity .............................................. 5
References ........................................................ 6 References ........................................................ 6
Security Considerations ........................................... 6 Security Considerations ........................................... 6
Author's Address .................................................. 6 Author's Address .................................................. 6
 End of changes. 9 change blocks. 
20 lines changed or deleted 37 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/