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