| < 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/ | ||||