idnits 2.17.1 draft-ietf-tls-https-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-18) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard 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 7 instances of too long lines in the document, the longest one being 27 characters in excess of 72. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'PKIX' ** Obsolete normative reference: RFC 2068 (Obsoleted by RFC 2616) -- Possible downref: Non-RFC (?) normative reference: ref. 'TLS' Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 E. Rescorla 3 INTERNET-DRAFT Terisa Systems, Inc. 4 January 1998 (Expires July-98) 6 HTTP Over TLS 8 Status of this Memo 10 This document is an Internet-Draft. 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 18 material or to cite them other than as ``work in progress.'' 20 To learn the current status of any Internet-Draft, please check the 21 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 22 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 23 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 24 ftp.isi.edu (US West Coast). 25 Abstract 27 This memo describes how to use TLS to secure HTTP connections over 28 the Internet. Current practice is to layer HTTP over SSL (the prede- 29 cessor to TLS), distinguishing secured traffic from insecure traffic 30 by the use of a different server port. This document standardizes 31 that practice using TLS. A companion document describes a method for 32 using HTTP/TLS over the same port as normal HTTP. 34 1. Introduction 36 HTTP [RFC2068] was originally used in the clear on the Internet. 37 However, increased use of HTTP for sensitive applications has 38 required security measures. SSL, and its successor TLS [TLS] were 39 designed to provide channel-oriented security. This document 40 describes how to use HTTP over TLS. 42 1.1. Discussion of this Draft 44 This draft is being discussed on the "ietf-apps-tls" mailing list. To 45 subscribe, send a message to: 47 ietf-apps-tls-request@imc.org 49 with the single word 50 subscribe 52 in the body of the message. There is a Web site for the mailing list 53 at . 55 1.2. Requirements Terminology 57 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and 58 "MAY" that appear in this document are to be interpreted as described 59 in [RFC2119]. 61 2. HTTP Over TLS 63 Conceptually, HTTP/TLS is very simple. Simply use HTTP over TLS pre- 64 cisely as you would use HTTP over TCP. 66 2.1. Connection Initiation 68 The agent acting as the HTTP client should also act as the TLS 69 client. It should initiate a connection to the server on the 70 appropriate port and then send the TLS ClientHello to begin the TLS 71 handshake. When the TLS handshake has finished. The client may then 72 initiate the first HTTP request. All HTTP data MUST be sent using as 73 TLS "application data". Normal HTTP behavior, including retained 74 connections should be followed. 76 2.2. Connection Closure 78 TLS provides a facility for secure connection closure. When a valid 79 closure alert is received, an implementation can be assured that no 80 further data will be received on that connection. TLS implementa- 81 tions MUST initiate an exchange of closure alerts before closing a 82 connection. A TLS implementation MAY, after sending a closure alert, 83 close the connection without waiting for the peer to send its closure 84 alert, generating an "incomplete close". Note that an implementation 85 which does this MAY choose to reuse the session. This SHOULD only be 86 done when the application knows (typically through detecting HTTP 87 message boundaries) that it has received all the message data that it 88 cares about. 90 As specified in [TLS], any implementation which receives a connection 91 close without first receiving a valid closure alert (a "premature 92 close") MUST NOT reuse that session. Note that a premature close does 93 not call into question the security of the data already received, but 94 simply indicates that subsequent data might have been truncated. 95 Because TLS is oblivious to HTTP request/response boundaries, it is 96 necessary to examine the HTTP data itself (specifically the Content- 97 Length header) to determine whether the truncation occurred inside a 98 message or between messages. 100 2.2.1. Client Behavior 102 Because HTTP uses connection closure to signal end of server data, 103 client implementations MUST treat any premature closes as errors and 104 the data received as potentially truncated. Two cases in particular 105 deserve special note: 107 A HTTP response without a Content-Length header. Since data length in 108 this situation is signalled by connection close a premature close 109 generated by the server cannot be distinguished from a spurious 110 close generated by an attacker. 112 A HTTP response with a valid Content-Length header closed before 113 all data has been read. Because TLS does not provide document oriented protection, it is 114 impossible to determine whether the server has miscomputed the 115 Content-Length or an attacker has truncated the connection. 117 When encountering a premature close, a client SHOULD treat as com- 118 pleted all requests for which it has received as much data as speci- 119 fied in the Content-Length header. 121 A client detecting an incomplete close SHOULD recover gracefully. It 122 MAY resume a TLS session closed in this fashion. 124 Clients MUST send a closure alert before closing the connection. 125 Clients which are unprepared to receive any more data MAY choose not 126 to wait for the server's closure alert and simply close the connec- 127 tion, thus generating an incomplete close on the server side. 129 2.2.2. Server Behavior 131 RFC2068 permits an HTTP client to close the connection at any time, 132 and requires servers to recover gracefully. In particular, servers 133 SHOULD be prepared to receive an incomplete close from the client, 134 since the client can often determine when the end of server data is. 135 Servers SHOULD be willing to resume TLS sessions closed in this 136 fashion. 138 Implementation note: In HTTP implementations which do not use per- 139 sistent connections, the server ordinarily expects to be able to sig- 140 nal end of data by closing the connection. When Content-Length is 141 used, however, the client may have already sent the closure alert and 142 dropped the connection. 144 Servers MUST attempt to initiate an exchange of closure alerts with 145 the client before closing the connection. Servers MAY close the con- 146 nection after sending the closure alert, thus generating an incom- 147 plete close on the client side. 149 2.3. Port Number 151 The first data that an HTTP server expects to receive from the client 152 is the Request-Line production. The first data that a TLS server (and 153 hence an HTTP/TLS server) expects to receive is the ClientHello. Con- 154 sequently, common practice has been to run HTTP/TLS over a separate 155 port in order to distinguish which protocol is being used. When 156 HTTP/TLS is being run over a TCP/IP connection, the default port is 157 443. This does not preclude HTTP/TLS from being run over another 158 transport. TLS only presumes a reliable connection-oriented data 159 stream. 161 2.4. URI Format 163 HTTP/TLS is differentiated from HTTP URIs by using the 'https' proto- 164 col identifier in place of the 'http' protocol identifier. An example 165 URI specifying HTTP/TLS is: 167 https://abc.com:80/~smith/home.html 169 3. Endpoint Identification 171 3.1. Server Identity 173 In general, HTTP/TLS requests are generated by dereferencing a URI. 174 As a consequence, the hostname for the server is known to the client. 175 If the hostname is available, the client MUST check it against the 176 server's identity as presented in the server's Certificate message, 177 in order to prevent man-in-the-middle attacks. 179 If a subjectAltName extension of type dNSName is present, that MUST 180 be used as the identity. Otherwise, the (most specific) Common Name 181 field in the Subject field of the certificate MUST be used. Although 182 the use of the Common Name is existing practice, it is deprecated and 183 Certification Authorities are encouraged to use the dNSName instead. 185 Matching is performed using the matching rules specified by [PKIX], 186 including wildcard matches. E.g. *.bar.com would match a.bar.com, 187 b.bar.com, etc. but not bar.com. If more than one identity of a given 188 type is present in the certificate (e.g. more than one dNSName name, 189 a match in any one of the set is considered acceptable.) 190 If the hostname does not match the identity in the certificate, user 191 oriented clients MUST either notify the user (clients MAY give the 192 user the opportunity to continue with the connection in any case) or 193 terminate the connection with a bad certificate error. Automated 194 clients MUST close the connection, returning a bad certificate error. 196 3.2. Client Identity 198 Typically, the server has no external knowledge of what the client's 199 identity ought to be and so checks (other than that the client has a 200 certificate chain rooted in an appropriate CA) are not possible. If a 201 server has such knowledge (typically from some source external to 202 HTTP or TLS) it SHOULD check the identity as described above. 204 References 205 [PKIX] R. Housley, W. Ford, W. Polk, D. Solo, Internet Public Key 206 Infrastructure: Part I: X.509 Certificate and CRL Profile, 207 , October 1997. 209 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 210 Berners-Lee, T., "Hypertext Transfer Protocol -- HTTP/1.1" 211 RFC 2068, January 1997. 213 [RFC2119] Bradner, S., "Key Words for use in RFCs to indicate 214 Requirement Levels", RFC2119, March 1997. 216 [TLS] Dierks, T., Allen, C., "The TLS Protocol", RFCXXXX, November 1997. 218 Security Considerations 220 This entire document is about security. 222 Author's Address 224 Eric Rescorla 225 Terisa Systems, Inc. 226 4984 El Camino Real 227 Los Altos, CA 94022 228 Phone: (650) 919-1753 229 Table of Contents 231 1. Introduction ................................................... 1 233 1.1. Discussion of this Draft ..................................... 1 235 1.2. Requirements Terminology ..................................... 2 237 2. HTTP Over TLS .................................................. 2 239 2.1. Connection Initiation ........................................ 2 241 2.2. Connection Closure ........................................... 2 243 2.2.1. Client Behavior ............................................ 3 245 2.2.2. Server Behavior ............................................ 3 247 2.3. Port Number .................................................. 4 249 2.4. URI Format ................................................... 4 251 3. Endpoint Identification ........................................ 4 253 3.1. Server Identity .............................................. 4 255 RN Client Identity ................................................ 5 257 References ........................................................ 6 259 Security Considerations ........................................... 6 261 Author's Address .................................................. 6