1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
7 |
Network Working Group R. Khare |
8 |
Request for Comments: 2817 4K Associates / UC Irvine |
9 |
Updates: 2616 S. Lawrence |
10 |
Category: Standards Track Agranat Systems, Inc. |
11 |
May 2000 |
12 |
|
13 |
|
14 |
Upgrading to TLS Within HTTP/1.1 |
15 |
|
16 |
Status of this Memo |
17 |
|
18 |
This document specifies an Internet standards track protocol for the |
19 |
Internet community, and requests discussion and suggestions for |
20 |
improvements. Please refer to the current edition of the "Internet |
21 |
Official Protocol Standards" (STD 1) for the standardization state |
22 |
and status of this protocol. Distribution of this memo is unlimited. |
23 |
|
24 |
Copyright Notice |
25 |
|
26 |
Copyright (C) The Internet Society (2000). All Rights Reserved. |
27 |
|
28 |
Abstract |
29 |
|
30 |
This memo explains how to use the Upgrade mechanism in HTTP/1.1 to |
31 |
initiate Transport Layer Security (TLS) over an existing TCP |
32 |
connection. This allows unsecured and secured HTTP traffic to share |
33 |
the same well known port (in this case, http: at 80 rather than |
34 |
https: at 443). It also enables "virtual hosting", so a single HTTP + |
35 |
TLS server can disambiguate traffic intended for several hostnames at |
36 |
a single IP address. |
37 |
|
38 |
Since HTTP/1.1 [1] defines Upgrade as a hop-by-hop mechanism, this |
39 |
memo also documents the HTTP CONNECT method for establishing end-to- |
40 |
end tunnels across HTTP proxies. Finally, this memo establishes new |
41 |
IANA registries for public HTTP status codes, as well as public or |
42 |
private Upgrade product tokens. |
43 |
|
44 |
This memo does NOT affect the current definition of the 'https' URI |
45 |
scheme, which already defines a separate namespace |
46 |
(http://example.org/ and https://example.org/ are not equivalent). |
47 |
|
48 |
|
49 |
|
50 |
|
51 |
|
52 |
|
53 |
|
54 |
|
55 |
|
56 |
|
57 |
|
58 |
Khare & Lawrence Standards Track [Page 1] |
59 |
|
60 |
RFC 2817 HTTP Upgrade to TLS May 2000 |
61 |
|
62 |
|
63 |
Table of Contents |
64 |
|
65 |
1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 2 |
66 |
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 |
67 |
2.1 Requirements Terminology . . . . . . . . . . . . . . . . . . . 4 |
68 |
3. Client Requested Upgrade to HTTP over TLS . . . . . . . . . . 4 |
69 |
3.1 Optional Upgrade . . . . . . . . . . . . . . . . . . . . . . . 4 |
70 |
3.2 Mandatory Upgrade . . . . . . . . . . . . . . . . . . . . . . 4 |
71 |
3.3 Server Acceptance of Upgrade Request . . . . . . . . . . . . . 4 |
72 |
4. Server Requested Upgrade to HTTP over TLS . . . . . . . . . . 5 |
73 |
4.1 Optional Advertisement . . . . . . . . . . . . . . . . . . . . 5 |
74 |
4.2 Mandatory Advertisement . . . . . . . . . . . . . . . . . . . 5 |
75 |
5. Upgrade across Proxies . . . . . . . . . . . . . . . . . . . . 6 |
76 |
5.1 Implications of Hop By Hop Upgrade . . . . . . . . . . . . . . 6 |
77 |
5.2 Requesting a Tunnel with CONNECT . . . . . . . . . . . . . . . 6 |
78 |
5.3 Establishing a Tunnel with CONNECT . . . . . . . . . . . . . . 7 |
79 |
6. Rationale for the use of a 4xx (client error) Status Code . . 7 |
80 |
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 |
81 |
7.1 HTTP Status Code Registry . . . . . . . . . . . . . . . . . . 8 |
82 |
7.2 HTTP Upgrade Token Registry . . . . . . . . . . . . . . . . . 8 |
83 |
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 |
84 |
8.1 Implications for the https: URI Scheme . . . . . . . . . . . . 10 |
85 |
8.2 Security Considerations for CONNECT . . . . . . . . . . . . . 10 |
86 |
References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 |
87 |
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 |
88 |
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 |
89 |
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13 |
90 |
|
91 |
1. Motivation |
92 |
|
93 |
The historical practice of deploying HTTP over SSL3 [3] has |
94 |
distinguished the combination from HTTP alone by a unique URI scheme |
95 |
and the TCP port number. The scheme 'http' meant the HTTP protocol |
96 |
alone on port 80, while 'https' meant the HTTP protocol over SSL on |
97 |
port 443. Parallel well-known port numbers have similarly been |
98 |
requested -- and in some cases, granted -- to distinguish between |
99 |
secured and unsecured use of other application protocols (e.g. |
100 |
snews, ftps). This approach effectively halves the number of |
101 |
available well known ports. |
102 |
|
103 |
At the Washington DC IETF meeting in December 1997, the Applications |
104 |
Area Directors and the IESG reaffirmed that the practice of issuing |
105 |
parallel "secure" port numbers should be deprecated. The HTTP/1.1 |
106 |
Upgrade mechanism can apply Transport Layer Security [6] to an open |
107 |
HTTP connection. |
108 |
|
109 |
|
110 |
|
111 |
|
112 |
|
113 |
|
114 |
Khare & Lawrence Standards Track [Page 2] |
115 |
|
116 |
RFC 2817 HTTP Upgrade to TLS May 2000 |
117 |
|
118 |
|
119 |
In the nearly two years since, there has been broad acceptance of the |
120 |
concept behind this proposal, but little interest in implementing |
121 |
alternatives to port 443 for generic Web browsing. In fact, nothing |
122 |
in this memo affects the current interpretation of https: URIs. |
123 |
However, new application protocols built atop HTTP, such as the |
124 |
Internet Printing Protocol [7], call for just such a mechanism in |
125 |
order to move ahead in the IETF standards process. |
126 |
|
127 |
The Upgrade mechanism also solves the "virtual hosting" problem. |
128 |
Rather than allocating multiple IP addresses to a single host, an |
129 |
HTTP/1.1 server will use the Host: header to disambiguate the |
130 |
intended web service. As HTTP/1.1 usage has grown more prevalent, |
131 |
more ISPs are offering name-based virtual hosting, thus delaying IP |
132 |
address space exhaustion. |
133 |
|
134 |
TLS (and SSL) have been hobbled by the same limitation as earlier |
135 |
versions of HTTP: the initial handshake does not specify the intended |
136 |
hostname, relying exclusively on the IP address. Using a cleartext |
137 |
HTTP/1.1 Upgrade: preamble to the TLS handshake -- choosing the |
138 |
certificates based on the initial Host: header -- will allow ISPs to |
139 |
provide secure name-based virtual hosting as well. |
140 |
|
141 |
2. Introduction |
142 |
|
143 |
TLS, a.k.a., SSL (Secure Sockets Layer), establishes a private end- |
144 |
to-end connection, optionally including strong mutual authentication, |
145 |
using a variety of cryptosystems. Initially, a handshake phase uses |
146 |
three subprotocols to set up a record layer, authenticate endpoints, |
147 |
set parameters, as well as report errors. Then, there is an ongoing |
148 |
layered record protocol that handles encryption, compression, and |
149 |
reassembly for the remainder of the connection. The latter is |
150 |
intended to be completely transparent. For example, there is no |
151 |
dependency between TLS's record markers and or certificates and |
152 |
HTTP/1.1's chunked encoding or authentication. |
153 |
|
154 |
Either the client or server can use the HTTP/1.1 [1] Upgrade |
155 |
mechanism (Section 14.42) to indicate that a TLS-secured connection |
156 |
is desired or necessary. This memo defines the "TLS/1.0" Upgrade |
157 |
token, and a new HTTP Status Code, "426 Upgrade Required". |
158 |
|
159 |
Section 3 and Section 4 describe the operation of a directly |
160 |
connected client and server. Intermediate proxies must establish an |
161 |
end-to-end tunnel before applying those operations, as explained in |
162 |
Section 5. |
163 |
|
164 |
|
165 |
|
166 |
|
167 |
|
168 |
|
169 |
|
170 |
Khare & Lawrence Standards Track [Page 3] |
171 |
|
172 |
RFC 2817 HTTP Upgrade to TLS May 2000 |
173 |
|
174 |
|
175 |
2.1 Requirements Terminology |
176 |
|
177 |
Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and |
178 |
"MAY" that appear in this document are to be interpreted as described |
179 |
in RFC 2119 [11]. |
180 |
|
181 |
3. Client Requested Upgrade to HTTP over TLS |
182 |
|
183 |
When the client sends an HTTP/1.1 request with an Upgrade header |
184 |
field containing the token "TLS/1.0", it is requesting the server to |
185 |
complete the current HTTP/1.1 request after switching to TLS/1.0. |
186 |
|
187 |
3.1 Optional Upgrade |
188 |
|
189 |
A client MAY offer to switch to secured operation during any clear |
190 |
HTTP request when an unsecured response would be acceptable: |
191 |
|
192 |
GET http://example.bank.com/acct_stat.html?749394889300 HTTP/1.1 |
193 |
Host: example.bank.com |
194 |
Upgrade: TLS/1.0 |
195 |
Connection: Upgrade |
196 |
|
197 |
In this case, the server MAY respond to the clear HTTP operation |
198 |
normally, OR switch to secured operation (as detailed in the next |
199 |
section). |
200 |
|
201 |
Note that HTTP/1.1 [1] specifies "the upgrade keyword MUST be |
202 |
supplied within a Connection header field (section 14.10) whenever |
203 |
Upgrade is present in an HTTP/1.1 message". |
204 |
|
205 |
3.2 Mandatory Upgrade |
206 |
|
207 |
If an unsecured response would be unacceptable, a client MUST send an |
208 |
OPTIONS request first to complete the switch to TLS/1.0 (if |
209 |
possible). |
210 |
|
211 |
OPTIONS * HTTP/1.1 |
212 |
Host: example.bank.com |
213 |
Upgrade: TLS/1.0 |
214 |
Connection: Upgrade |
215 |
|
216 |
3.3 Server Acceptance of Upgrade Request |
217 |
|
218 |
As specified in HTTP/1.1 [1], if the server is prepared to initiate |
219 |
the TLS handshake, it MUST send the intermediate "101 Switching |
220 |
Protocol" and MUST include an Upgrade response header specifying the |
221 |
tokens of the protocol stack it is switching to: |
222 |
|
223 |
|
224 |
|
225 |
|
226 |
Khare & Lawrence Standards Track [Page 4] |
227 |
|
228 |
RFC 2817 HTTP Upgrade to TLS May 2000 |
229 |
|
230 |
|
231 |
HTTP/1.1 101 Switching Protocols |
232 |
Upgrade: TLS/1.0, HTTP/1.1 |
233 |
Connection: Upgrade |
234 |
|
235 |
Note that the protocol tokens listed in the Upgrade header of a 101 |
236 |
Switching Protocols response specify an ordered 'bottom-up' stack. |
237 |
|
238 |
As specified in HTTP/1.1 [1], Section 10.1.2: "The server will |
239 |
switch protocols to those defined by the response's Upgrade header |
240 |
field immediately after the empty line which terminates the 101 |
241 |
response". |
242 |
|
243 |
Once the TLS handshake completes successfully, the server MUST |
244 |
continue with the response to the original request. Any TLS handshake |
245 |
failure MUST lead to disconnection, per the TLS error alert |
246 |
specification. |
247 |
|
248 |
4. Server Requested Upgrade to HTTP over TLS |
249 |
|
250 |
The Upgrade response header field advertises possible protocol |
251 |
upgrades a server MAY accept. In conjunction with the "426 Upgrade |
252 |
Required" status code, a server can advertise the exact protocol |
253 |
upgrade(s) that a client MUST accept to complete the request. |
254 |
|
255 |
4.1 Optional Advertisement |
256 |
|
257 |
As specified in HTTP/1.1 [1], the server MAY include an Upgrade |
258 |
header in any response other than 101 or 426 to indicate a |
259 |
willingness to switch to any (combination) of the protocols listed. |
260 |
|
261 |
4.2 Mandatory Advertisement |
262 |
|
263 |
A server MAY indicate that a client request can not be completed |
264 |
without TLS using the "426 Upgrade Required" status code, which MUST |
265 |
include an an Upgrade header field specifying the token of the |
266 |
required TLS version. |
267 |
|
268 |
HTTP/1.1 426 Upgrade Required |
269 |
Upgrade: TLS/1.0, HTTP/1.1 |
270 |
Connection: Upgrade |
271 |
|
272 |
The server SHOULD include a message body in the 426 response which |
273 |
indicates in human readable form the reason for the error and |
274 |
describes any alternative courses which may be available to the user. |
275 |
|
276 |
Note that even if a client is willing to use TLS, it must use the |
277 |
operations in Section 3 to proceed; the TLS handshake cannot begin |
278 |
immediately after the 426 response. |
279 |
|
280 |
|
281 |
|
282 |
Khare & Lawrence Standards Track [Page 5] |
283 |
|
284 |
RFC 2817 HTTP Upgrade to TLS May 2000 |
285 |
|
286 |
|
287 |
5. Upgrade across Proxies |
288 |
|
289 |
As a hop-by-hop header, Upgrade is negotiated between each pair of |
290 |
HTTP counterparties. If a User Agent sends a request with an Upgrade |
291 |
header to a proxy, it is requesting a change to the protocol between |
292 |
itself and the proxy, not an end-to-end change. |
293 |
|
294 |
Since TLS, in particular, requires end-to-end connectivity to provide |
295 |
authentication and prevent man-in-the-middle attacks, this memo |
296 |
specifies the CONNECT method to establish a tunnel across proxies. |
297 |
|
298 |
Once a tunnel is established, any of the operations in Section 3 can |
299 |
be used to establish a TLS connection. |
300 |
|
301 |
5.1 Implications of Hop By Hop Upgrade |
302 |
|
303 |
If an origin server receives an Upgrade header from a proxy and |
304 |
responds with a 101 Switching Protocols response, it is changing the |
305 |
protocol only on the connection between the proxy and itself. |
306 |
Similarly, a proxy might return a 101 response to its client to |
307 |
change the protocol on that connection independently of the protocols |
308 |
it is using to communicate toward the origin server. |
309 |
|
310 |
These scenarios also complicate diagnosis of a 426 response. Since |
311 |
Upgrade is a hop-by-hop header, a proxy that does not recognize 426 |
312 |
might remove the accompanying Upgrade header and prevent the client |
313 |
from determining the required protocol switch. If a client receives |
314 |
a 426 status without an accompanying Upgrade header, it will need to |
315 |
request an end to end tunnel connection as described in Section 5.2 |
316 |
and repeat the request in order to obtain the required upgrade |
317 |
information. |
318 |
|
319 |
This hop-by-hop definition of Upgrade was a deliberate choice. It |
320 |
allows for incremental deployment on either side of proxies, and for |
321 |
optimized protocols between cascaded proxies without the knowledge of |
322 |
the parties that are not a part of the change. |
323 |
|
324 |
5.2 Requesting a Tunnel with CONNECT |
325 |
|
326 |
A CONNECT method requests that a proxy establish a tunnel connection |
327 |
on its behalf. The Request-URI portion of the Request-Line is always |
328 |
an 'authority' as defined by URI Generic Syntax [2], which is to say |
329 |
the host name and port number destination of the requested connection |
330 |
separated by a colon: |
331 |
|
332 |
CONNECT server.example.com:80 HTTP/1.1 |
333 |
Host: server.example.com:80 |
334 |
|
335 |
|
336 |
|
337 |
|
338 |
Khare & Lawrence Standards Track [Page 6] |
339 |
|
340 |
RFC 2817 HTTP Upgrade to TLS May 2000 |
341 |
|
342 |
|
343 |
Other HTTP mechanisms can be used normally with the CONNECT method -- |
344 |
except end-to-end protocol Upgrade requests, of course, since the |
345 |
tunnel must be established first. |
346 |
|
347 |
For example, proxy authentication might be used to establish the |
348 |
authority to create a tunnel: |
349 |
|
350 |
CONNECT server.example.com:80 HTTP/1.1 |
351 |
Host: server.example.com:80 |
352 |
Proxy-Authorization: basic aGVsbG86d29ybGQ= |
353 |
|
354 |
Like any other pipelined HTTP/1.1 request, data to be tunneled may be |
355 |
sent immediately after the blank line. The usual caveats also apply: |
356 |
data may be discarded if the eventual response is negative, and the |
357 |
connection may be reset with no response if more than one TCP segment |
358 |
is outstanding. |
359 |
|
360 |
5.3 Establishing a Tunnel with CONNECT |
361 |
|
362 |
Any successful (2xx) response to a CONNECT request indicates that the |
363 |
proxy has established a connection to the requested host and port, |
364 |
and has switched to tunneling the current connection to that server |
365 |
connection. |
366 |
|
367 |
It may be the case that the proxy itself can only reach the requested |
368 |
origin server through another proxy. In this case, the first proxy |
369 |
SHOULD make a CONNECT request of that next proxy, requesting a tunnel |
370 |
to the authority. A proxy MUST NOT respond with any 2xx status code |
371 |
unless it has either a direct or tunnel connection established to the |
372 |
authority. |
373 |
|
374 |
An origin server which receives a CONNECT request for itself MAY |
375 |
respond with a 2xx status code to indicate that a connection is |
376 |
established. |
377 |
|
378 |
If at any point either one of the peers gets disconnected, any |
379 |
outstanding data that came from that peer will be passed to the other |
380 |
one, and after that also the other connection will be terminated by |
381 |
the proxy. If there is outstanding data to that peer undelivered, |
382 |
that data will be discarded. |
383 |
|
384 |
6. Rationale for the use of a 4xx (client error) Status Code |
385 |
|
386 |
Reliable, interoperable negotiation of Upgrade features requires an |
387 |
unambiguous failure signal. The 426 Upgrade Required status code |
388 |
allows a server to definitively state the precise protocol extensions |
389 |
a given resource must be served with. |
390 |
|
391 |
|
392 |
|
393 |
|
394 |
Khare & Lawrence Standards Track [Page 7] |
395 |
|
396 |
RFC 2817 HTTP Upgrade to TLS May 2000 |
397 |
|
398 |
|
399 |
It might at first appear that the response should have been some form |
400 |
of redirection (a 3xx code), by analogy to an old-style redirection |
401 |
to an https: URI. User agents that do not understand Upgrade: |
402 |
preclude this. |
403 |
|
404 |
Suppose that a 3xx code had been assigned for "Upgrade Required"; a |
405 |
user agent that did not recognize it would treat it as 300. It would |
406 |
then properly look for a "Location" header in the response and |
407 |
attempt to repeat the request at the URL in that header field. Since |
408 |
it did not know to Upgrade to incorporate the TLS layer, it would at |
409 |
best fail again at the new URL. |
410 |
|
411 |
7. IANA Considerations |
412 |
|
413 |
IANA shall create registries for two name spaces, as described in BCP |
414 |
26 [10]: |
415 |
|
416 |
o HTTP Status Codes |
417 |
o HTTP Upgrade Tokens |
418 |
|
419 |
7.1 HTTP Status Code Registry |
420 |
|
421 |
The HTTP Status Code Registry defines the name space for the Status- |
422 |
Code token in the Status line of an HTTP response. The initial |
423 |
values for this name space are those specified by: |
424 |
|
425 |
1. Draft Standard for HTTP/1.1 [1] |
426 |
2. Web Distributed Authoring and Versioning [4] [defines 420-424] |
427 |
3. WebDAV Advanced Collections [5] (Work in Progress) [defines 425] |
428 |
4. Section 6 [defines 426] |
429 |
|
430 |
Values to be added to this name space SHOULD be subject to review in |
431 |
the form of a standards track document within the IETF Applications |
432 |
Area. Any such document SHOULD be traceable through statuses of |
433 |
either 'Obsoletes' or 'Updates' to the Draft Standard for |
434 |
HTTP/1.1 [1]. |
435 |
|
436 |
7.2 HTTP Upgrade Token Registry |
437 |
|
438 |
The HTTP Upgrade Token Registry defines the name space for product |
439 |
tokens used to identify protocols in the Upgrade HTTP header field. |
440 |
Each registered token should be associated with one or a set of |
441 |
specifications, and with contact information. |
442 |
|
443 |
The Draft Standard for HTTP/1.1 [1] specifies that these tokens obey |
444 |
the production for 'product': |
445 |
|
446 |
|
447 |
|
448 |
|
449 |
|
450 |
Khare & Lawrence Standards Track [Page 8] |
451 |
|
452 |
RFC 2817 HTTP Upgrade to TLS May 2000 |
453 |
|
454 |
|
455 |
product = token ["/" product-version] |
456 |
product-version = token |
457 |
|
458 |
Registrations should be allowed on a First Come First Served basis as |
459 |
described in BCP 26 [10]. These specifications need not be IETF |
460 |
documents or be subject to IESG review, but should obey the following |
461 |
rules: |
462 |
|
463 |
1. A token, once registered, stays registered forever. |
464 |
2. The registration MUST name a responsible party for the |
465 |
registration. |
466 |
3. The registration MUST name a point of contact. |
467 |
4. The registration MAY name the documentation required for the |
468 |
token. |
469 |
5. The responsible party MAY change the registration at any time. |
470 |
The IANA will keep a record of all such changes, and make them |
471 |
available upon request. |
472 |
6. The responsible party for the first registration of a "product" |
473 |
token MUST approve later registrations of a "version" token |
474 |
together with that "product" token before they can be registered. |
475 |
7. If absolutely required, the IESG MAY reassign the responsibility |
476 |
for a token. This will normally only be used in the case when a |
477 |
responsible party cannot be contacted. |
478 |
|
479 |
This specification defines the protocol token "TLS/1.0" as the |
480 |
identifier for the protocol specified by The TLS Protocol [6]. |
481 |
|
482 |
It is NOT required that specifications for upgrade tokens be made |
483 |
publicly available, but the contact information for the registration |
484 |
SHOULD be. |
485 |
|
486 |
8. Security Considerations |
487 |
|
488 |
The potential for a man-in-the-middle attack (deleting the Upgrade |
489 |
header) remains the same as current, mixed http/https practice: |
490 |
|
491 |
o Removing the Upgrade header is similar to rewriting web pages to |
492 |
change https:// links to http:// links. |
493 |
o The risk is only present if the server is willing to vend such |
494 |
information over both a secure and an insecure channel in the |
495 |
first place. |
496 |
o If the client knows for a fact that a server is TLS-compliant, it |
497 |
can insist on it by only sending an Upgrade request with a no-op |
498 |
method like OPTIONS. |
499 |
o Finally, as the https: specification warns, "users should |
500 |
carefully examine the certificate presented by the server to |
501 |
determine if it meets their expectations". |
502 |
|
503 |
|
504 |
|
505 |
|
506 |
Khare & Lawrence Standards Track [Page 9] |
507 |
|
508 |
RFC 2817 HTTP Upgrade to TLS May 2000 |
509 |
|
510 |
|
511 |
Furthermore, for clients that do not explicitly try to invoke TLS, |
512 |
servers can use the Upgrade header in any response other than 101 or |
513 |
426 to advertise TLS compliance. Since TLS compliance should be |
514 |
considered a feature of the server and not the resource at hand, it |
515 |
should be sufficient to send it once, and let clients cache that |
516 |
fact. |
517 |
|
518 |
8.1 Implications for the https: URI Scheme |
519 |
|
520 |
While nothing in this memo affects the definition of the 'https' URI |
521 |
scheme, widespread adoption of this mechanism for HyperText content |
522 |
could use 'http' to identify both secure and non-secure resources. |
523 |
|
524 |
The choice of what security characteristics are required on the |
525 |
connection is left to the client and server. This allows either |
526 |
party to use any information available in making this determination. |
527 |
For example, user agents may rely on user preference settings or |
528 |
information about the security of the network such as 'TLS required |
529 |
on all POST operations not on my local net', or servers may apply |
530 |
resource access rules such as 'the FORM on this page must be served |
531 |
and submitted using TLS'. |
532 |
|
533 |
8.2 Security Considerations for CONNECT |
534 |
|
535 |
A generic TCP tunnel is fraught with security risks. First, such |
536 |
authorization should be limited to a small number of known ports. |
537 |
The Upgrade: mechanism defined here only requires onward tunneling at |
538 |
port 80. Second, since tunneled data is opaque to the proxy, there |
539 |
are additional risks to tunneling to other well-known or reserved |
540 |
ports. A putative HTTP client CONNECTing to port 25 could relay spam |
541 |
via SMTP, for example. |
542 |
|
543 |
References |
544 |
|
545 |
[1] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., |
546 |
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- |
547 |
HTTP/1.1", RFC 2616, June 1999. |
548 |
|
549 |
[2] Berners-Lee, T., Fielding, R. and L. Masinter, "URI Generic |
550 |
Syntax", RFC 2396, August 1998. |
551 |
|
552 |
[3] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. |
553 |
|
554 |
[4] Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. Jensen, |
555 |
"Web Distributed Authoring and Versioning", RFC 2518, February |
556 |
1999. |
557 |
|
558 |
|
559 |
|
560 |
|
561 |
|
562 |
Khare & Lawrence Standards Track [Page 10] |
563 |
|
564 |
RFC 2817 HTTP Upgrade to TLS May 2000 |
565 |
|
566 |
|
567 |
[5] Slein, J., Whitehead, E.J., et al., "WebDAV Advanced Collections |
568 |
Protocol", Work In Progress. |
569 |
|
570 |
[6] Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, January |
571 |
1999. |
572 |
|
573 |
[7] Herriot, R., Butler, S., Moore, P. and R. Turner, "Internet |
574 |
Printing Protocol/1.0: Encoding and Transport", RFC 2565, April |
575 |
1999. |
576 |
|
577 |
[8] Luotonen, A., "Tunneling TCP based protocols through Web proxy |
578 |
servers", Work In Progress. (Also available in: Luotonen, Ari. |
579 |
Web Proxy Servers, Prentice-Hall, 1997 ISBN:0136806120.) |
580 |
|
581 |
[9] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June |
582 |
1999. |
583 |
|
584 |
[10] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA |
585 |
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. |
586 |
|
587 |
[11] Bradner, S., "Key words for use in RFCs to Indicate Requirement |
588 |
Levels", BCP 14, RFC 2119, March 1997. |
589 |
|
590 |
Authors' Addresses |
591 |
|
592 |
Rohit Khare |
593 |
4K Associates / UC Irvine |
594 |
3207 Palo Verde |
595 |
Irvine, CA 92612 |
596 |
US |
597 |
|
598 |
Phone: +1 626 806 7574 |
599 |
EMail: rohit@4K-associates.com |
600 |
URI: http://www.4K-associates.com/ |
601 |
|
602 |
|
603 |
Scott Lawrence |
604 |
Agranat Systems, Inc. |
605 |
5 Clocktower Place |
606 |
Suite 400 |
607 |
Maynard, MA 01754 |
608 |
US |
609 |
|
610 |
Phone: +1 978 461 0888 |
611 |
EMail: lawrence@agranat.com |
612 |
URI: http://www.agranat.com/ |
613 |
|
614 |
|
615 |
|
616 |
|
617 |
|
618 |
Khare & Lawrence Standards Track [Page 11] |
619 |
|
620 |
RFC 2817 HTTP Upgrade to TLS May 2000 |
621 |
|
622 |
|
623 |
Appendix A. Acknowledgments |
624 |
|
625 |
The CONNECT method was originally described in a Work in Progress |
626 |
titled, "Tunneling TCP based protocols through Web proxy servers", |
627 |
[8] by Ari Luotonen of Netscape Communications Corporation. It was |
628 |
widely implemented by HTTP proxies, but was never made a part of any |
629 |
IETF Standards Track document. The method name CONNECT was reserved, |
630 |
but not defined in [1]. |
631 |
|
632 |
The definition provided here is derived directly from that earlier |
633 |
memo, with some editorial changes and conformance to the stylistic |
634 |
conventions since established in other HTTP specifications. |
635 |
|
636 |
Additional Thanks to: |
637 |
|
638 |
o Paul Hoffman for his work on the STARTTLS command extension for |
639 |
ESMTP. |
640 |
o Roy Fielding for assistance with the rationale behind Upgrade: |
641 |
and its interaction with OPTIONS. |
642 |
o Eric Rescorla for his work on standardizing the existing https: |
643 |
practice to compare with. |
644 |
o Marshall Rose, for the xml2rfc document type description and tools |
645 |
[9]. |
646 |
o Jim Whitehead, for sorting out the current range of available HTTP |
647 |
status codes. |
648 |
o Henrik Frystyk Nielsen, whose work on the Mandatory extension |
649 |
mechanism pointed out a hop-by-hop Upgrade still requires |
650 |
tunneling. |
651 |
o Harald Alvestrand for improvements to the token registration |
652 |
rules. |
653 |
|
654 |
|
655 |
|
656 |
|
657 |
|
658 |
|
659 |
|
660 |
|
661 |
|
662 |
|
663 |
|
664 |
|
665 |
|
666 |
|
667 |
|
668 |
|
669 |
|
670 |
|
671 |
|
672 |
|
673 |
|
674 |
Khare & Lawrence Standards Track [Page 12] |
675 |
|
676 |
RFC 2817 HTTP Upgrade to TLS May 2000 |
677 |
|
678 |
|
679 |
Full Copyright Statement |
680 |
|
681 |
Copyright (C) The Internet Society (2000). All Rights Reserved. |
682 |
|
683 |
This document and translations of it may be copied and furnished to |
684 |
others, and derivative works that comment on or otherwise explain it |
685 |
or assist in its implementation may be prepared, copied, published |
686 |
and distributed, in whole or in part, without restriction of any |
687 |
kind, provided that the above copyright notice and this paragraph are |
688 |
included on all such copies and derivative works. However, this |
689 |
document itself may not be modified in any way, such as by removing |
690 |
the copyright notice or references to the Internet Society or other |
691 |
Internet organizations, except as needed for the purpose of |
692 |
developing Internet standards in which case the procedures for |
693 |
copyrights defined in the Internet Standards process must be |
694 |
followed, or as required to translate it into languages other than |
695 |
English. |
696 |
|
697 |
The limited permissions granted above are perpetual and will not be |
698 |
revoked by the Internet Society or its successors or assigns. |
699 |
|
700 |
This document and the information contained herein is provided on an |
701 |
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING |
702 |
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING |
703 |
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION |
704 |
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF |
705 |
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. |
706 |
|
707 |
Acknowledgement |
708 |
|
709 |
Funding for the RFC Editor function is currently provided by the |
710 |
Internet Society. |
711 |
|
712 |
|
713 |
|
714 |
|
715 |
|
716 |
|
717 |
|
718 |
|
719 |
|
720 |
|
721 |
|
722 |
|
723 |
|
724 |
|
725 |
|
726 |
|
727 |
|
728 |
|
729 |
|
730 |
Khare & Lawrence Standards Track [Page 13] |
731 |
|