idnits 2.17.00 (12 Aug 2021) /tmp/idnits36060/draft-ietf-tls-https-02.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? ** 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. 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) ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 3 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 1998 (Expires March-99) 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 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 documents that 31 practice using TLS. A companion document describes a method for using 32 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 48 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 sentas TLS 73 "application data". Normal HTTP behavior, including retained connec- 74 tions 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 the client has external information as to the expected identity of 180 the server, the hostname check MAY be omitted. (For instance, a 181 client may be connecting to a machine whose address and hostname are 182 dynamic but the client knows the certificate that the server will 183 present.) In such cases, it is important to narrow the scope of 184 acceptable certificates as much as possible in order to prevent man 185 in the middle attacks. In special cases, it may be appropriate for 186 the client to simply ignore the server's identity, but it must be 187 understood that this leaves the connection open to active attack. 189 If a subjectAltName extension of type dNSName is present, that MUST 190 be used as the identity. Otherwise, the (most specific) Common Name 191 field in the Subject field of the certificate MUST be used. Although 192 the use of the Common Name is existing practice, it is deprecated and 193 Certification Authorities are encouraged to use the dNSName instead. 195 Matching is performed using the matching rules specified by [PKIX]. 196 If more than one identity of a given type is present in the certifi- 197 cate (e.g. more than one dNSName name, a match in any one of the set 198 is considered acceptable.) Names may contain the wildcard character * 199 which is considered to match any single domain name component or com- 200 ponent fragment. E.g. *.a.com matches foo.a.com but not 201 bar.foo.a.com. f*.com matches foo.com but not bar.com. 203 If the hostname does not match the identity in the certificate, user 204 oriented clients MUST either notify the user (clients MAY give the 205 user the opportunity to continue with the connection in any case) or 206 terminate the connection with a bad certificate error. Automated 207 clients MUST log the error to an appropriate audit log (if available) 208 and SHOULD terminate the connection (with a bad certificate error). 209 Automated clients MAY provide a configuration setting that disables 210 this check, but MUST provide a setting which enables it. 212 Note that in many cases the URI itself comes from an untrusted 213 source. The above-described check provides no protection against 214 attacks where this source is compromised. For example, if the URI was 215 obtained by clicking on an HTML page which was itself obtained 216 without using HTTP/TLS, a man in the middle could have replaced the 217 URI. In order to prevent this form of attack, users should carefully 218 examine the certificate presented by the server to determine if it 219 meets their expectations. 221 3.2. Client Identity 223 Typically, the server has no external knowledge of what the client's 224 identity ought to be and so checks (other than that the client has a 225 certificate chain rooted in an appropriate CA) are not possible. If a 226 server has such knowledge (typically from some source external to 227 HTTP or TLS) it SHOULD check the identity as described above. 229 References 230 [PKIX] R. Housley, W. Ford, W. Polk, D. Solo, Internet Public Key 231 Infrastructure: Part I: X.509 Certificate and CRL Profile, 232 , October 1997. 234 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 235 Berners-Lee, T., "Hypertext Transfer Protocol -- HTTP/1.1" 236 RFC 2068, January 1997. 238 [RFC2119] Bradner, S., "Key Words for use in RFCs to indicate 239 Requirement Levels", RFC2119, March 1997. 241 [TLS] Dierks, T., Allen, C., "The TLS Protocol", RFC2246, January 1999. 243 Security Considerations 245 This entire document is about security. 247 Author's Address 249 Eric Rescorla 250 RTFM, Inc. 251 30 Newell Road, #16 252 East Palo Alto, CA 94303 253 Phone: (650) 328-8631 254 Table of Contents 256 1. Introduction ................................................... 1 258 1.1. Discussion of this Draft ..................................... 1 260 1.2. Requirements Terminology ..................................... 2 262 2. HTTP Over TLS .................................................. 2 264 2.1. Connection Initiation ........................................ 2 266 2.2. Connection Closure ........................................... 2 268 2.2.1. Client Behavior ............................................ 3 270 2.2.2. Server Behavior ............................................ 3 272 2.3. Port Number .................................................. 4 274 2.4. URI Format ................................................... 4 276 3. Endpoint Identification ........................................ 4 278 3.1. Server Identity .............................................. 4 280 3.2. Client Identity .............................................. 5 282 References ........................................................ 6 284 Security Considerations ........................................... 6 286 Author's Address .................................................. 6