source: draft-ietf-httpbis/orig/rfc2818.xml @ 661

Last change on this file since 661 was 598, checked in by julian.reschke@…, 10 years ago

fix Makefile, add RFC 2817/2818, re-gen HTML

  • Property svn:eol-style set to native
  • Property svn:executable set to *
File size: 16.3 KB
Line 
1<?xml version="1.0" encoding="UTF-8"?>
2<!DOCTYPE rfc [
3  <!ENTITY MAY "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MAY</bcp14>">
4  <!ENTITY MUST "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MUST</bcp14>">
5  <!ENTITY MUST-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>MUST NOT</bcp14>">
6  <!ENTITY OPTIONAL "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>OPTIONAL</bcp14>">
7  <!ENTITY RECOMMENDED "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>RECOMMENDED</bcp14>">
8  <!ENTITY REQUIRED "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>REQUIRED</bcp14>">
9  <!ENTITY SHALL "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHALL</bcp14>">
10  <!ENTITY SHALL-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHALL NOT</bcp14>">
11  <!ENTITY SHOULD "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD</bcp14>">
12  <!ENTITY SHOULD-NOT "<bcp14 xmlns='http://purl.org/net/xml2rfc/ext'>SHOULD NOT</bcp14>">
13]>
14<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
15<?rfc toc="yes" ?>
16<?rfc tocdepth="3" ?>
17<?rfc tocindent="no" ?>
18<?rfc symrefs="yes" ?>
19<?rfc sortrefs="no"?>
20<?rfc iprnotified="no" ?>
21<?rfc strict="yes" ?>
22<?rfc compact="yes" ?>
23<?rfc comments="yes" ?>
24<?rfc inline="yes" ?>
25<?rfc rfcedstyle="yes" ?>
26<rfc number="2818" category="info">
27 <front>
28  <title>HTTP Over TLS</title>
29  <author initials="E." surname="Rescorla" fullname="Eric Rescorla">
30   <organization>RTFM, Inc.</organization>
31   <address>           
32      <postal>
33        <street>30 Newell Road, #16</street>
34        <city>East Palo Alto</city><region>CA</region><code>94303</code>
35      </postal>
36      <phone>(650) 328-8631</phone>
37      <email>ekr@rtfm.com</email>       
38        </address>
39  </author>
40  <date month="May" year="2000"/>
41
42  <abstract>
43  <t>
44   This memo describes how to use TLS to secure HTTP connections over
45   the Internet. Current practice is to layer HTTP over SSL (the
46   predecessor to TLS), distinguishing secured traffic from insecure
47   traffic by the use of a different server port. This document
48   documents that practice using TLS. A companion document describes a
49   method for using HTTP/TLS over the same port as normal HTTP
50   [RFC2817].
51  </t>
52  </abstract>
53
54 </front>
55
56 <middle>
57
58<section title="Introduction">
59<t>
60   HTTP <xref target="RFC2616"/> was originally used in the clear on the Internet.
61   However, increased use of HTTP for sensitive applications has
62   required security measures. SSL, and its successor TLS <xref target="RFC2246"/> were
63   designed to provide channel-oriented security. This document
64   describes how to use HTTP over TLS.
65</t>
66
67<section title="Requirements Terminology">
68<t>
69   Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
70   "MAY" that appear in this document are to be interpreted as described
71   in <xref target="RFC2119"/>.
72</t>
73</section>
74
75</section>
76
77<section title="HTTP Over TLS">
78<t>
79   Conceptually, HTTP/TLS is very simple. Simply use HTTP over TLS
80   precisely as you would use HTTP over TCP.
81</t>
82
83<section title="Connection Initiation">
84<t>
85   The agent acting as the HTTP client should also act as the TLS
86   client.  It should initiate a connection to the server on the
87   appropriate port and then send the TLS ClientHello to begin the TLS
88   handshake. When the TLS handshake has finished. The client may then
89   initiate the first HTTP request.  All HTTP data &MUST; be sent as TLS
90   "application data".  Normal HTTP behavior, including retained
91   connections should be followed.
92</t>
93</section>
94
95<section title="Connection Closure">
96<t>
97   TLS provides a facility for secure connection closure. When a valid
98   closure alert is received, an implementation can be assured that no
99   further data will be received on that connection.  TLS
100   implementations &MUST; initiate an exchange of closure alerts before
101   closing a connection. A TLS implementation &MAY;, after sending a
102   closure alert, close the connection without waiting for the peer to
103   send its closure alert, generating an "incomplete close".  Note that
104   an implementation which does this &MAY; choose to reuse the session.
105   This &SHOULD; only be done when the application knows (typically
106   through detecting HTTP message boundaries) that it has received all
107   the message data that it cares about.
108</t>
109<t>
110   As specified in <xref target="RFC2246"/>, any implementation which receives a
111   connection close without first receiving a valid closure alert (a
112   "premature close") &MUST-NOT; reuse that session.  Note that a
113   premature close does not call into question the security of the data
114   already received, but simply indicates that subsequent data might
115   have been truncated. Because TLS is oblivious to HTTP
116   request/response boundaries, it is necessary to examine the HTTP data
117   itself (specifically the Content-Length header) to determine whether
118   the truncation occurred inside a message or between messages.
119</t>
120
121<section title="Client Behavior">
122<t>
123   Because HTTP uses connection closure to signal end of server data,
124   client implementations &MUST; treat any premature closes as errors and
125   the data received as potentially truncated.  While in some cases the
126   HTTP protocol allows the client to find out whether truncation took
127   place so that, if it received the complete reply, it may tolerate
128   such errors following the principle to "[be] strict when sending and
129   tolerant when receiving" [RFC1958], often truncation does not show in
130   the HTTP protocol data; two cases in particular deserve special note:
131</t>
132<t><list><t>
133     A HTTP response without a Content-Length header. Since data length
134     in this situation is signalled by connection close a premature
135     close generated by the server cannot be distinguished from a
136     spurious close generated by an attacker.
137</t><t>
138     A HTTP response with a valid Content-Length header closed before
139     all data has been read. Because TLS does not provide document
140     oriented protection, it is impossible to determine whether the
141     server has miscomputed the Content-Length or an attacker has
142     truncated the connection.
143</t></list></t>
144<t>
145   There is one exception to the above rule. When encountering a
146   premature close, a client &SHOULD; treat as completed all requests for
147   which it has received as much data as specified in the Content-Length
148   header.
149</t>
150<t>
151   A client detecting an incomplete close &SHOULD; recover gracefully.  It
152   &MAY; resume a TLS session closed in this fashion.
153</t>
154<t>
155   Clients &MUST; send a closure alert before closing the connection.
156   Clients which are unprepared to receive any more data &MAY; choose not
157   to wait for the server's closure alert and simply close the
158   connection, thus generating an incomplete close on the server side.
159</t>
160</section>
161
162<section title="Server Behavior">
163<t>
164   RFC 2616 permits an HTTP client to close the connection at any time,
165   and requires servers to recover gracefully.  In particular, servers
166   &SHOULD; be prepared to receive an incomplete close from the client,
167   since the client can often determine when the end of server data is.
168   Servers &SHOULD; be willing to resume TLS sessions closed in this
169   fashion.
170</t>
171<t>
172   Implementation note: In HTTP implementations which do not use
173   persistent connections, the server ordinarily expects to be able to
174   signal end of data by closing the connection. When Content-Length is
175   used, however, the client may have already sent the closure alert and
176   dropped the connection.
177</t>
178<t>
179   Servers &MUST; attempt to initiate an exchange of closure alerts with
180   the client before closing the connection. Servers &MAY; close the
181   connection after sending the closure alert, thus generating an
182   incomplete close on the client side.
183</t>
184</section>
185</section>
186
187<section title="Port Number">
188<t>
189   The first data that an HTTP server expects to receive from the client
190   is the Request-Line production. The first data that a TLS server (and
191   hence an HTTP/TLS server) expects to receive is the ClientHello.
192   Consequently, common practice has been to run HTTP/TLS over a
193   separate port in order to distinguish which protocol is being used.
194   When HTTP/TLS is being run over a TCP/IP connection, the default port
195   is 443. This does not preclude HTTP/TLS from being run over another
196   transport. TLS only presumes a reliable connection-oriented data
197   stream.
198</t>
199</section>
200
201<section title="URI Format">
202<iref item="https URI scheme" primary="true"/> 
203<iref item="URI scheme" subitem="https" primary="true"/> 
204<t>
205   HTTP/TLS is differentiated from HTTP URIs by using the 'https'
206   protocol identifier in place of the 'http' protocol identifier. An
207   example URI specifying HTTP/TLS is:
208</t>
209<figure><artwork type="example">
210  https://www.example.com/~smith/home.html
211</artwork></figure>
212</section>
213</section>
214
215<section title="Endpoint Identification">
216
217<section title="Server Identity">
218<t>
219   In general, HTTP/TLS requests are generated by dereferencing a URI.
220   As a consequence, the hostname for the server is known to the client.
221   If the hostname is available, the client &MUST; check it against the
222   server's identity as presented in the server's Certificate message,
223   in order to prevent man-in-the-middle attacks.
224</t>
225<t>
226   If the client has external information as to the expected identity of
227   the server, the hostname check &MAY; be omitted. (For instance, a
228   client may be connecting to a machine whose address and hostname are
229   dynamic but the client knows the certificate that the server will
230   present.) In such cases, it is important to narrow the scope of
231   acceptable certificates as much as possible in order to prevent man
232   in the middle attacks.  In special cases, it may be appropriate for
233   the client to simply ignore the server's identity, but it must be
234   understood that this leaves the connection open to active attack.
235</t>
236<t>
237   If a subjectAltName extension of type dNSName is present, that &MUST;
238   be used as the identity. Otherwise, the (most specific) Common Name
239   field in the Subject field of the certificate &MUST; be used. Although
240   the use of the Common Name is existing practice, it is deprecated and
241   Certification Authorities are encouraged to use the dNSName instead.
242</t>
243<t>
244   Matching is performed using the matching rules specified by
245   <xref target="RFC2459"/>.  If more than one identity of a given type is present in
246   the certificate (e.g., more than one dNSName name, a match in any one
247   of the set is considered acceptable.) Names may contain the wildcard
248   character * which is considered to match any single domain name
249   component or component fragment. E.g., *.a.com matches foo.a.com but
250   not bar.foo.a.com. f*.com matches foo.com but not bar.com.
251</t>
252<t>
253   In some cases, the URI is specified as an IP address rather than a
254   hostname. In this case, the iPAddress subjectAltName must be present
255   in the certificate and must exactly match the IP in the URI.
256</t>
257<t>
258   If the hostname does not match the identity in the certificate, user
259   oriented clients &MUST; either notify the user (clients &MAY; give the
260   user the opportunity to continue with the connection in any case) or
261   terminate the connection with a bad certificate error. Automated
262   clients &MUST; log the error to an appropriate audit log (if available)
263   and &SHOULD; terminate the connection (with a bad certificate error).
264   Automated clients &MAY; provide a configuration setting that disables
265   this check, but &MUST; provide a setting which enables it.
266</t>
267<t>
268   Note that in many cases the URI itself comes from an untrusted
269   source. The above-described check provides no protection against
270   attacks where this source is compromised. For example, if the URI was
271   obtained by clicking on an HTML page which was itself obtained
272   without using HTTP/TLS, a man in the middle could have replaced the
273   URI.  In order to prevent this form of attack, users should carefully
274   examine the certificate presented by the server to determine if it
275   meets their expectations.
276</t>
277</section>
278
279<section title="Client Identity">
280<t>
281   Typically, the server has no external knowledge of what the client's
282   identity ought to be and so checks (other than that the client has a
283   certificate chain rooted in an appropriate CA) are not possible. If a
284   server has such knowledge (typically from some source external to
285   HTTP or TLS) it &SHOULD; check the identity as described above.
286</t>
287</section>
288
289</section>
290
291
292 </middle>
293 <back>
294 
295<references>
296
297<reference anchor='RFC2459'>
298  <front>
299    <title abbrev='Internet Public Key Infrastructure'>Internet X.509 Public Key Infrastructure Certificate and CRL Profile</title>
300    <author initials='R.' surname='Housley' fullname='Russell Housley'>
301      <organization>SPYRUS</organization>
302      <address><email>housley@spyrus.com</email></address>
303    </author>
304    <author initials='W.' surname='Ford' fullname='Warwick Ford'>
305      <organization>VeriSign, Inc.</organization>
306      <address><email>wford@verisign.com</email></address>
307    </author>
308    <author initials='T.' surname='Polk' fullname='Tim Polk'>
309      <organization>NIST</organization>
310      <address><email>wpolk@nist.gov</email></address>
311    </author>
312    <author initials='D.' surname='Solo' fullname='David Solo'>
313      <organization>Citicorp</organization>
314      <address><email>david.solo@citicorp.com</email></address>
315    </author>
316    <date year='1999' month='January' />
317  </front>
318  <seriesInfo name='RFC' value='2459' />
319</reference>
320
321<reference anchor="RFC2616">
322  <front>
323    <title>Hypertext Transfer Protocol -- HTTP/1.1</title>
324    <author initials="R." surname="Fielding" fullname="R. Fielding">
325      <organization>University of California, Irvine</organization>
326      <address><email>fielding@ics.uci.edu</email></address>
327    </author>
328    <author initials="J." surname="Gettys" fullname="J. Gettys">
329      <organization>W3C</organization>
330      <address><email>jg@w3.org</email></address>
331    </author>
332    <author initials="J." surname="Mogul" fullname="J. Mogul">
333      <organization>Compaq Computer Corporation</organization>
334      <address><email>mogul@wrl.dec.com</email></address>
335    </author>
336    <author initials="H." surname="Frystyk" fullname="H. Frystyk">
337      <organization>MIT Laboratory for Computer Science</organization>
338      <address><email>frystyk@w3.org</email></address>
339    </author>
340    <author initials="L." surname="Masinter" fullname="L. Masinter">
341      <organization>Xerox Corporation</organization>
342      <address><email>masinter@parc.xerox.com</email></address>
343    </author>
344    <author initials="P." surname="Leach" fullname="P. Leach">
345      <organization>Microsoft Corporation</organization>
346      <address><email>paulle@microsoft.com</email></address>
347    </author>
348    <author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee">
349      <organization>W3C</organization>
350      <address><email>timbl@w3.org</email></address>
351    </author>
352    <date month="June" year="1999"/>
353  </front>
354  <seriesInfo name="RFC" value="2616"/>
355</reference>
356
357<reference anchor="RFC2119">
358  <front>
359    <title>Key words for use in RFCs to Indicate Requirement Levels</title>
360    <author initials="S." surname="Bradner" fullname="Scott Bradner">
361      <organization>Harvard University</organization>
362      <address><email>sob@harvard.edu</email></address>
363    </author>
364    <date month="March" year="1997"/>
365  </front>
366  <seriesInfo name="BCP" value="14"/>
367  <seriesInfo name="RFC" value="2119"/>
368</reference>
369
370<reference anchor='RFC2246'>
371  <front>
372    <title>The TLS Protocol Version 1.0</title>
373    <author initials='T.' surname='Dierks' fullname='Tim Dierks'>
374    <organization>Certicom</organization>
375    <address>
376    <email>tdierks@certicom.com</email></address></author>
377    <author initials='C.' surname='Allen' fullname='Christopher Allen'>
378    <organization>Certicom</organization>
379    <address>
380    <email>callen@certicom.com</email></address></author>
381    <date year='1999' month='January' />
382  </front>
383  <seriesInfo name='RFC' value='2246' />
384</reference>
385
386<reference anchor='RFC2817'>
387  <front>
388    <title>Upgrading to TLS Within HTTP/1.1</title>
389    <author initials='R.' surname='Khare' fullname='R. Khare'>
390      <organization />
391    </author>
392    <author initials='S.' surname='Lawrence' fullname='S. Lawrence'>
393      <organization />
394    </author>
395    <date year='2000' month='May' />
396  </front>
397  <seriesInfo name='RFC' value='2817' />
398</reference>
399
400</references>
401 
402<section title="Security Considerations">
403<t>
404   This entire document is about security.
405</t>
406</section>
407
408 
409 </back>
410</rfc>
Note: See TracBrowser for help on using the repository browser.