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