/[hydra]/hydra/docs/rfc/rfc2818.txt
ViewVC logotype

Contents of /hydra/docs/rfc/rfc2818.txt

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.1 - (show annotations)
Sun Sep 29 16:01:34 2002 UTC (21 years, 6 months ago) by nmav
Branch: MAIN
CVS Tags: hydra_0_1_6_without_hic, hydra_0_0_8, hydra_0_0_9, hydra_0_0_6, hydra_0_0_7, hydra_0_0_4, hydra_0_0_5, hydra_0_1_3, hydra_0_1_2, hydra_0_1_1, hydra_0_1_0, hydra_0_1_7, hydra_0_1_6, hydra_0_1_4, hydra_0_1_8, hydra_0_0_10, HEAD
Branch point for: hydra_0_1_0_patches
File MIME type: text/plain
Added RFCs and drafts about HTTP

1
2
3
4
5
6
7 Network Working Group E. Rescorla
8 Request for Comments: 2818 RTFM, Inc.
9 Category: Informational May 2000
10
11
12 HTTP Over TLS
13
14 Status of this Memo
15
16 This memo provides information for the Internet community. It does
17 not specify an Internet standard of any kind. Distribution of this
18 memo is unlimited.
19
20 Copyright Notice
21
22 Copyright (C) The Internet Society (2000). All Rights Reserved.
23
24 Abstract
25
26 This memo describes how to use TLS to secure HTTP connections over
27 the Internet. Current practice is to layer HTTP over SSL (the
28 predecessor to TLS), distinguishing secured traffic from insecure
29 traffic by the use of a different server port. This document
30 documents that practice using TLS. A companion document describes a
31 method for using HTTP/TLS over the same port as normal HTTP
32 [RFC2817].
33
34 Table of Contents
35
36 1. Introduction . . . . . . . . . . . . . . . . . . . . . . 2
37 1.1. Requirements Terminology . . . . . . . . . . . . . . . 2
38 2. HTTP Over TLS . . . . . . . . . . . . . . . . . . . . . . 2
39 2.1. Connection Initiation . . . . . . . . . . . . . . . . . 2
40 2.2. Connection Closure . . . . . . . . . . . . . . . . . . 2
41 2.2.1. Client Behavior . . . . . . . . . . . . . . . . . . . 3
42 2.2.2. Server Behavior . . . . . . . . . . . . . . . . . . . 3
43 2.3. Port Number . . . . . . . . . . . . . . . . . . . . . . 4
44 2.4. URI Format . . . . . . . . . . . . . . . . . . . . . . 4
45 3. Endpoint Identification . . . . . . . . . . . . . . . . . 4
46 3.1. Server Identity . . . . . . . . . . . . . . . . . . . . 4
47 3.2. Client Identity . . . . . . . . . . . . . . . . . . . . 5
48 References . . . . . . . . . . . . . . . . . . . . . . . . . 6
49 Security Considerations . . . . . . . . . . . . . . . . . . 6
50 Author's Address . . . . . . . . . . . . . . . . . . . . . . 6
51 Full Copyright Statement . . . . . . . . . . . . . . . . . . 7
52
53
54
55
56
57
58 Rescorla Informational [Page 1]
59
60 RFC 2818 HTTP Over TLS May 2000
61
62
63 1. Introduction
64
65 HTTP [RFC2616] was originally used in the clear on the Internet.
66 However, increased use of HTTP for sensitive applications has
67 required security measures. SSL, and its successor TLS [RFC2246] were
68 designed to provide channel-oriented security. This document
69 describes how to use HTTP over TLS.
70
71 1.1. Requirements Terminology
72
73 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
74 "MAY" that appear in this document are to be interpreted as described
75 in [RFC2119].
76
77 2. HTTP Over TLS
78
79 Conceptually, HTTP/TLS is very simple. Simply use HTTP over TLS
80 precisely as you would use HTTP over TCP.
81
82 2.1. Connection Initiation
83
84 The agent acting as the HTTP client should also act as the TLS
85 client. It should initiate a connection to the server on the
86 appropriate port and then send the TLS ClientHello to begin the TLS
87 handshake. When the TLS handshake has finished. The client may then
88 initiate the first HTTP request. All HTTP data MUST be sent as TLS
89 "application data". Normal HTTP behavior, including retained
90 connections should be followed.
91
92 2.2. Connection Closure
93
94 TLS provides a facility for secure connection closure. When a valid
95 closure alert is received, an implementation can be assured that no
96 further data will be received on that connection. TLS
97 implementations MUST initiate an exchange of closure alerts before
98 closing a connection. A TLS implementation MAY, after sending a
99 closure alert, close the connection without waiting for the peer to
100 send its closure alert, generating an "incomplete close". Note that
101 an implementation which does this MAY choose to reuse the session.
102 This SHOULD only be done when the application knows (typically
103 through detecting HTTP message boundaries) that it has received all
104 the message data that it cares about.
105
106 As specified in [RFC2246], any implementation which receives a
107 connection close without first receiving a valid closure alert (a
108 "premature close") MUST NOT reuse that session. Note that a
109 premature close does not call into question the security of the data
110 already received, but simply indicates that subsequent data might
111
112
113
114 Rescorla Informational [Page 2]
115
116 RFC 2818 HTTP Over TLS May 2000
117
118
119 have been truncated. Because TLS is oblivious to HTTP
120 request/response boundaries, it is necessary to examine the HTTP data
121 itself (specifically the Content-Length header) to determine whether
122 the truncation occurred inside a message or between messages.
123
124 2.2.1. Client Behavior
125
126 Because HTTP uses connection closure to signal end of server data,
127 client implementations MUST treat any premature closes as errors and
128 the data received as potentially truncated. While in some cases the
129 HTTP protocol allows the client to find out whether truncation took
130 place so that, if it received the complete reply, it may tolerate
131 such errors following the principle to "[be] strict when sending and
132 tolerant when receiving" [RFC1958], often truncation does not show in
133 the HTTP protocol data; two cases in particular deserve special note:
134
135 A HTTP response without a Content-Length header. Since data length
136 in this situation is signalled by connection close a premature
137 close generated by the server cannot be distinguished from a
138 spurious close generated by an attacker.
139
140 A HTTP response with a valid Content-Length header closed before
141 all data has been read. Because TLS does not provide document
142 oriented protection, it is impossible to determine whether the
143 server has miscomputed the Content-Length or an attacker has
144 truncated the connection.
145
146 There is one exception to the above rule. When encountering a
147 premature close, a client SHOULD treat as completed all requests for
148 which it has received as much data as specified in the Content-Length
149 header.
150
151 A client detecting an incomplete close SHOULD recover gracefully. It
152 MAY resume a TLS session closed in this fashion.
153
154 Clients MUST send a closure alert before closing the connection.
155 Clients which are unprepared to receive any more data MAY choose not
156 to wait for the server's closure alert and simply close the
157 connection, thus generating an incomplete close on the server side.
158
159 2.2.2. Server Behavior
160
161 RFC 2616 permits an HTTP client to close the connection at any time,
162 and requires servers to recover gracefully. In particular, servers
163 SHOULD be prepared to receive an incomplete close from the client,
164 since the client can often determine when the end of server data is.
165 Servers SHOULD be willing to resume TLS sessions closed in this
166 fashion.
167
168
169
170 Rescorla Informational [Page 3]
171
172 RFC 2818 HTTP Over TLS May 2000
173
174
175 Implementation note: In HTTP implementations which do not use
176 persistent connections, the server ordinarily expects to be able to
177 signal end of data by closing the connection. When Content-Length is
178 used, however, the client may have already sent the closure alert and
179 dropped the connection.
180
181 Servers MUST attempt to initiate an exchange of closure alerts with
182 the client before closing the connection. Servers MAY close the
183 connection after sending the closure alert, thus generating an
184 incomplete close on the client side.
185
186 2.3. Port Number
187
188 The first data that an HTTP server expects to receive from the client
189 is the Request-Line production. The first data that a TLS server (and
190 hence an HTTP/TLS server) expects to receive is the ClientHello.
191 Consequently, common practice has been to run HTTP/TLS over a
192 separate port in order to distinguish which protocol is being used.
193 When HTTP/TLS is being run over a TCP/IP connection, the default port
194 is 443. This does not preclude HTTP/TLS from being run over another
195 transport. TLS only presumes a reliable connection-oriented data
196 stream.
197
198 2.4. URI Format
199
200 HTTP/TLS is differentiated from HTTP URIs by using the 'https'
201 protocol identifier in place of the 'http' protocol identifier. An
202 example URI specifying HTTP/TLS is:
203
204 https://www.example.com/~smith/home.html
205
206 3. Endpoint Identification
207
208 3.1. Server Identity
209
210 In general, HTTP/TLS requests are generated by dereferencing a URI.
211 As a consequence, the hostname for the server is known to the client.
212 If the hostname is available, the client MUST check it against the
213 server's identity as presented in the server's Certificate message,
214 in order to prevent man-in-the-middle attacks.
215
216 If the client has external information as to the expected identity of
217 the server, the hostname check MAY be omitted. (For instance, a
218 client may be connecting to a machine whose address and hostname are
219 dynamic but the client knows the certificate that the server will
220 present.) In such cases, it is important to narrow the scope of
221 acceptable certificates as much as possible in order to prevent man
222
223
224
225
226 Rescorla Informational [Page 4]
227
228 RFC 2818 HTTP Over TLS May 2000
229
230
231 in the middle attacks. In special cases, it may be appropriate for
232 the client to simply ignore the server's identity, but it must be
233 understood that this leaves the connection open to active attack.
234
235 If a subjectAltName extension of type dNSName is present, that MUST
236 be used as the identity. Otherwise, the (most specific) Common Name
237 field in the Subject field of the certificate MUST be used. Although
238 the use of the Common Name is existing practice, it is deprecated and
239 Certification Authorities are encouraged to use the dNSName instead.
240
241 Matching is performed using the matching rules specified by
242 [RFC2459]. If more than one identity of a given type is present in
243 the certificate (e.g., more than one dNSName name, a match in any one
244 of the set is considered acceptable.) Names may contain the wildcard
245 character * which is considered to match any single domain name
246 component or component fragment. E.g., *.a.com matches foo.a.com but
247 not bar.foo.a.com. f*.com matches foo.com but not bar.com.
248
249 In some cases, the URI is specified as an IP address rather than a
250 hostname. In this case, the iPAddress subjectAltName must be present
251 in the certificate and must exactly match the IP in the URI.
252
253 If the hostname does not match the identity in the certificate, user
254 oriented clients MUST either notify the user (clients MAY give the
255 user the opportunity to continue with the connection in any case) or
256 terminate the connection with a bad certificate error. Automated
257 clients MUST log the error to an appropriate audit log (if available)
258 and SHOULD terminate the connection (with a bad certificate error).
259 Automated clients MAY provide a configuration setting that disables
260 this check, but MUST provide a setting which enables it.
261
262 Note that in many cases the URI itself comes from an untrusted
263 source. The above-described check provides no protection against
264 attacks where this source is compromised. For example, if the URI was
265 obtained by clicking on an HTML page which was itself obtained
266 without using HTTP/TLS, a man in the middle could have replaced the
267 URI. In order to prevent this form of attack, users should carefully
268 examine the certificate presented by the server to determine if it
269 meets their expectations.
270
271 3.2. Client Identity
272
273 Typically, the server has no external knowledge of what the client's
274 identity ought to be and so checks (other than that the client has a
275 certificate chain rooted in an appropriate CA) are not possible. If a
276 server has such knowledge (typically from some source external to
277 HTTP or TLS) it SHOULD check the identity as described above.
278
279
280
281
282 Rescorla Informational [Page 5]
283
284 RFC 2818 HTTP Over TLS May 2000
285
286
287 References
288
289 [RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
290 Public Key Infrastructure: Part I: X.509 Certificate and
291 CRL Profile", RFC 2459, January 1999.
292
293 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,
294 L., Leach, P. and T. Berners-Lee, "Hypertext Transfer
295 Protocol, HTTP/1.1", RFC 2616, June 1999.
296
297 [RFC2119] Bradner, S., "Key Words for use in RFCs to indicate
298 Requirement Levels", BCP 14, RFC 2119, March 1997.
299
300 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246,
301 January 1999.
302
303 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
304 HTTP/1.1", RFC 2817, May 2000.
305
306 Security Considerations
307
308 This entire document is about security.
309
310 Author's Address
311
312 Eric Rescorla
313 RTFM, Inc.
314 30 Newell Road, #16
315 East Palo Alto, CA 94303
316
317 Phone: (650) 328-8631
318 EMail: ekr@rtfm.com
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338 Rescorla Informational [Page 6]
339
340 RFC 2818 HTTP Over TLS May 2000
341
342
343 Full Copyright Statement
344
345 Copyright (C) The Internet Society (2000). All Rights Reserved.
346
347 This document and translations of it may be copied and furnished to
348 others, and derivative works that comment on or otherwise explain it
349 or assist in its implementation may be prepared, copied, published
350 and distributed, in whole or in part, without restriction of any
351 kind, provided that the above copyright notice and this paragraph are
352 included on all such copies and derivative works. However, this
353 document itself may not be modified in any way, such as by removing
354 the copyright notice or references to the Internet Society or other
355 Internet organizations, except as needed for the purpose of
356 developing Internet standards in which case the procedures for
357 copyrights defined in the Internet Standards process must be
358 followed, or as required to translate it into languages other than
359 English.
360
361 The limited permissions granted above are perpetual and will not be
362 revoked by the Internet Society or its successors or assigns.
363
364 This document and the information contained herein is provided on an
365 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
366 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
367 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
368 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
369 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
370
371 Acknowledgement
372
373 Funding for the RFC Editor function is currently provided by the
374 Internet Society.
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394 Rescorla Informational [Page 7]
395

webmaster@linux.gr
ViewVC Help
Powered by ViewVC 1.1.26