idnits 2.17.1 draft-ietf-tls-https-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2616' is mentioned on line 43, but not defined ** Obsolete undefined reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Unused Reference: 'RFC-2616' is defined on line 255, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2459 (ref. 'PKIX') (Obsoleted by RFC 3280) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 E. Rescorla 2 INTERNET-DRAFT RTFM, Inc. 3 September 1999 (Expires March-00) 5 HTTP Over TLS 7 Status of this Memo 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC2026. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference mate- 18 rial or to cite them other than as ``work in progress.'' 20 The list of current Internet-Drafts can be accessed at 21 http://www.ietf.org/ietf/1id-abstracts.txt 23 The list of Internet-Draft Shadow Directories can be accessed at 24 http://www.ietf.org/shadow.html. 26 To learn the current status of any Internet-Draft, please check the 27 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 28 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 29 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 30 ftp.isi.edu (US West Coast). 32 Abstract 34 This memo describes how to use TLS to secure HTTP connections over 35 the Internet. Current practice is to layer HTTP over SSL (the prede- 36 cessor to TLS), distinguishing secured traffic from insecure traffic 37 by the use of a different server port. This document documents that 38 practice using TLS. A companion document describes a method for using 39 HTTP/TLS over the same port as normal HTTP. 41 1. Introduction 43 HTTP [RFC2616] was originally used in the clear on the Internet. 44 However, increased use of HTTP for sensitive applications has 45 required security measures. SSL, and its successor TLS [TLS] were 46 designed to provide channel-oriented security. This document 47 describes how to use HTTP over TLS. 49 1.1. Discussion of this Draft 51 This draft is being discussed on the "ietf-apps-tls" mailing list. To 52 subscribe, send a message to: 54 ietf-apps-tls-request@imc.org 56 Internet-Draft HTTP Over TLS 58 with the single word 60 subscribe 62 in the body of the message. There is a Web site for the mailing list at 63 . 65 1.2. Requirements Terminology 67 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and 68 "MAY" that appear in this document are to be interpreted as described 69 in [RFC2119]. 71 2. HTTP Over TLS 73 Conceptually, HTTP/TLS is very simple. Simply use HTTP over TLS pre- 74 cisely as you would use HTTP over TCP. 76 2.1. Connection Initiation 78 The agent acting as the HTTP client should also act as the TLS 79 client. It should initiate a connection to the server on the appro- 80 priate port and then send the TLS ClientHello to begin the TLS hand- 81 shake. When the TLS handshake has finished. The client may then ini- 82 tiate the first HTTP request. All HTTP data MUST be sentas TLS 83 "application data". Normal HTTP behavior, including retained connec- 84 tions should be followed. 86 2.2. Connection Closure 88 TLS provides a facility for secure connection closure. When a valid 89 closure alert is received, an implementation can be assured that no 90 further data will be received on that connection. TLS implementa- 91 tions MUST initiate an exchange of closure alerts before closing a 92 connection. A TLS implementation MAY, after sending a closure alert, 93 close the connection without waiting for the peer to send its closure 94 alert, generating an "incomplete close". Note that an implementation 95 which does this MAY choose to reuse the session. This SHOULD only be 96 done when the application knows (typically through detecting HTTP 97 message boundaries) that it has received all the message data that it 98 cares about. 100 As specified in [TLS], any implementation which receives a connection 101 close without first receiving a valid closure alert (a "premature 102 close") MUST NOT reuse that session. Note that a premature close 103 does not call into question the security of the data already 104 received, but simply indicates that subsequent data might have been 105 truncated. Because TLS is oblivious to HTTP request/response 107 Internet-Draft HTTP Over TLS 109 boundaries, it is necessary to examine the HTTP data itself (specifi- 110 cally the Content-Length header) to determine whether the truncation 111 occurred inside a message or between messages. 113 2.2.1. Client Behavior 115 Because HTTP uses connection closure to signal end of server data, 116 client implementations MUST treat any premature closes as errors and 117 the data received as potentially truncated. Two cases in particular 118 deserve special note: 120 A HTTP response without a Content-Length header. Since data length in 121 this situation is signalled by connection close a premature close 122 generated by the server cannot be distinguished from a spurious 123 close generated by an attacker. 125 A HTTP response with a valid Content-Length header closed before 126 all data has been read. Because TLS does not provide document 127 oriented protection, it is impossible to determine whether the 128 server has miscomputed the Content-Length or an attacker has 129 truncated the connection. 131 When encountering a premature close, a client SHOULD treat as com- 132 pleted all requests for which it has received as much data as speci- 133 fied in the Content-Length header. 135 A client detecting an incomplete close SHOULD recover gracefully. It 136 MAY resume a TLS session closed in this fashion. 138 Clients MUST send a closure alert before closing the connection. 139 Clients which are unprepared to receive any more data MAY choose not 140 to wait for the server's closure alert and simply close the connec- 141 tion, thus generating an incomplete close on the server side. 143 2.2.2. Server Behavior 145 RFC2068 permits an HTTP client to close the connection at any time, 146 and requires servers to recover gracefully. In particular, servers 147 SHOULD be prepared to receive an incomplete close from the client, 148 since the client can often determine when the end of server data is. 149 Servers SHOULD be willing to resume TLS sessions closed in this fash- 150 ion. 152 Implementation note: In HTTP implementations which do not use persis- 153 tent connections, the server ordinarily expects to be able to signal 154 end of data by closing the connection. When Content-Length is used, 155 however, the client may have already sent the closure alert and 157 Internet-Draft HTTP Over TLS 159 dropped the connection. 161 Servers MUST attempt to initiate an exchange of closure alerts with 162 the client before closing the connection. Servers MAY close the con- 163 nection after sending the closure alert, thus generating an incom- 164 plete close on the client side. 166 2.3. Port Number 168 The first data that an HTTP server expects to receive from the client 169 is the Request-Line production. The first data that a TLS server (and 170 hence an HTTP/TLS server) expects to receive is the ClientHello. Con- 171 sequently, common practice has been to run HTTP/TLS over a separate 172 port in order to distinguish which protocol is being used. When 173 HTTP/TLS is being run over a TCP/IP connection, the default port is 174 443. This does not preclude HTTP/TLS from being run over another 175 transport. TLS only presumes a reliable connection-oriented data 176 stream. 178 2.4. URI Format 180 HTTP/TLS is differentiated from HTTP URIs by using the 'https' proto- 181 col identifier in place of the 'http' protocol identifier. An example 182 URI specifying HTTP/TLS is: 184 https://www.example.com/~smith/home.html 186 3. Endpoint Identification 188 3.1. Server Identity 190 In general, HTTP/TLS requests are generated by dereferencing a URI. 191 As a consequence, the hostname for the server is known to the client. 192 If the hostname is available, the client MUST check it against the 193 server's identity as presented in the server's Certificate message, 194 in order to prevent man-in-the-middle attacks. 196 If the client has external information as to the expected identity of 197 the server, the hostname check MAY be omitted. (For instance, a 198 client may be connecting to a machine whose address and hostname are 199 dynamic but the client knows the certificate that the server will 200 present.) In such cases, it is important to narrow the scope of 201 acceptable certificates as much as possible in order to prevent man 202 in the middle attacks. In special cases, it may be appropriate for 203 the client to simply ignore the server's identity, but it must be 204 understood that this leaves the connection open to active attack. 206 Internet-Draft HTTP Over TLS 208 If a subjectAltName extension of type dNSName is present, that MUST 209 be used as the identity. Otherwise, the (most specific) Common Name 210 field in the Subject field of the certificate MUST be used. Although 211 the use of the Common Name is existing practice, it is deprecated and 212 Certification Authorities are encouraged to use the dNSName instead. 214 Matching is performed using the matching rules specified by [PKIX]. 215 If more than one identity of a given type is present in the certifi- 216 cate (e.g. more than one dNSName name, a match in any one of the set 217 is considered acceptable.) Names may contain the wildcard character * 218 which is considered to match any single domain name component or com- 219 ponent fragment. E.g. *.a.com matches foo.a.com but not 220 bar.foo.a.com. f*.com matches foo.com but not bar.com. 222 If the hostname does not match the identity in the certificate, user 223 oriented clients MUST either notify the user (clients MAY give the 224 user the opportunity to continue with the connection in any case) or 225 terminate the connection with a bad certificate error. Automated 226 clients MUST log the error to an appropriate audit log (if available) 227 and SHOULD terminate the connection (with a bad certificate error). 228 Automated clients MAY provide a configuration setting that disables 229 this check, but MUST provide a setting which enables it. 231 Note that in many cases the URI itself comes from an untrusted 232 source. The above-described check provides no protection against 233 attacks where this source is compromised. For example, if the URI was 234 obtained by clicking on an HTML page which was itself obtained with- 235 out using HTTP/TLS, a man in the middle could have replaced the URI. 236 In order to prevent this form of attack, users should carefully exam- 237 ine the certificate presented by the server to determine if it meets 238 their expectations. 240 3.2. Client Identity 242 Typically, the server has no external knowledge of what the client's 243 identity ought to be and so checks (other than that the client has a 244 certificate chain rooted in an appropriate CA) are not possible. If a 245 server has such knowledge (typically from some source external to 246 HTTP or TLS) it SHOULD check the identity as described above. 248 Internet-Draft HTTP Over TLS 250 References 251 [PKIX] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet 252 Public Key Infrastructure: Part I: X.509 Certificate and CRL 253 Profile", RFC 2459, January 1999. 255 [RFC-2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 256 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext 257 Transfer Protocol, HTTP/1.1" RFC 2616, June 1999. 259 [RFC2119] Bradner, S., "Key Words for use in RFCs to indicate 260 Requirement Levels", RFC2119, March 1997. 262 [TLS] Dierks, T., Allen, C., "The TLS Protocol", RFC2246, January 1999. 264 Security Considerations 266 This entire document is about security. 268 Author's Address 270 Eric Rescorla 271 RTFM, Inc. 272 30 Newell Road, #16 273 East Palo Alto, CA 94303 274 Phone: (650) 328-8631 276 Internet-Draft HTTP Over TLS 278 Table of Contents 280 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 1 281 1.1. Discussion of this Draft . . . . . . . . . . . . . . . . . . . 1 282 1.2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 2 283 2. HTTP Over TLS . . . . . . . . . . . . . . . . . . . . . . . . . . 2 284 2.1. Connection Initiation . . . . . . . . . . . . . . . . . . . . . 2 285 2.2. Connection Closure . . . . . . . . . . . . . . . . . . . . . . 2 286 2.2.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 3 287 2.2.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 3 288 2.3. Port Number . . . . . . . . . . . . . . . . . . . . . . . . . . 4 289 2.4. URI Format . . . . . . . . . . . . . . . . . . . . . . . . . . 4 290 3. Endpoint Identification . . . . . . . . . . . . . . . . . . . . . 4 291 3.1. Server Identity . . . . . . . . . . . . . . . . . . . . . . . . 4 292 3.2. Client Identity . . . . . . . . . . . . . . . . . . . . . . . . 5 293 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 294 Security Considerations . . . . . . . . . . . . . . . . . . . . . . 6 295 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . . 6