Ignore:
Timestamp:
20/01/14 07:43:53 (9 years ago)
Author:
julian.reschke@…
Message:

update rfc2617.xml (ABNF alignment was off from published version), regen all HTML

File:
1 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/orig/rfc2818.html

    r1305 r2564  
    22  PUBLIC "-//W3C//DTD HTML 4.01//EN">
    33<html lang="en">
    4    <head profile="http://www.w3.org/2006/03/hcard http://dublincore.org/documents/2008/08/04/dc-html/">
     4   <head profile="http://dublincore.org/documents/2008/08/04/dc-html/">
    55      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    66      <title>HTTP Over TLS</title><style type="text/css" title="Xml2Rfc (sans serif)">
    … …  
    2424body {
    2525  color: black;
    26   font-family: verdana, helvetica, arial, sans-serif;
    27   font-size: 10pt;
     26  font-family: cambria, helvetica, arial, sans-serif;
     27  font-size: 11pt;
     28  margin-right: 2em;
    2829}
    2930cite {
    3031  font-style: normal;
    3132}
    32 dd {
    33   margin-right: 2em;
    34 }
    3533dl {
    3634  margin-left: 2em;
    3735}
    38 
    3936ul.empty {
    4037  list-style-type: none;
    … …  
    5047}
    5148h1 {
    52   font-size: 14pt;
     49  font-size: 130%;
    5350  line-height: 21pt;
    5451  page-break-after: avoid;
    … …  
    5754  page-break-before: always;
    5855}
    59 h1 a {
    60   color: #333333;
    61 }
    6256h2 {
    63   font-size: 12pt;
     57  font-size: 120%;
    6458  line-height: 15pt;
    6559  page-break-after: avoid;
    6660}
    67 h3, h4, h5, h6 {
    68   font-size: 10pt;
     61h3 {
     62  font-size: 110%;
    6963  page-break-after: avoid;
    7064}
    71 h2 a, h3 a, h4 a, h5 a, h6 a {
     65h4, h5, h6 {
     66  page-break-after: avoid;
     67}
     68h1 a, h2 a, h3 a, h4 a, h5 a, h6 a {
    7269  color: black;
    7370}
    … …  
    7774li {
    7875  margin-left: 2em;
    79   margin-right: 2em;
    8076}
    8177ol {
    8278  margin-left: 2em;
    83   margin-right: 2em;
    8479}
    8580ol.la {
    … …  
    9489p {
    9590  margin-left: 2em;
    96   margin-right: 2em;
    9791}
    9892pre {
    … …  
    10094  background-color: lightyellow;
    10195  padding: .25em;
     96  page-break-inside: avoid;
    10297}
    10398pre.text2 {
    … …  
    129124  border-spacing: 1px;
    130125  width: 95%;
    131   font-size: 10pt;
     126  font-size: 11pt;
    132127  color: white;
    133128}
    … …  
    137132td.topnowrap {
    138133  vertical-align: top;
    139   white-space: nowrap; 
     134  white-space: nowrap;
    140135}
    141136table.header td {
    … …  
    154149  list-style: none;
    155150  margin-left: 1.5em;
    156   margin-right: 0em;
    157151  padding-left: 0em;
    158152}
    … …  
    160154  line-height: 150%;
    161155  font-weight: bold;
    162   font-size: 10pt;
    163156  margin-left: 0em;
    164   margin-right: 0em;
    165157}
    166158ul.toc li li {
    167159  line-height: normal;
    168160  font-weight: normal;
    169   font-size: 9pt;
     161  font-size: 10pt;
    170162  margin-left: 0em;
    171   margin-right: 0em;
    172163}
    173164li.excluded {
    … …  
    176167ul p {
    177168  margin-left: 0em;
     169}
     170.title, .filename, h1, h2, h3, h4 {
     171  font-family: candara, helvetica, arial, sans-serif;
     172}
     173samp, tt, code, pre {
     174  font: consolas, monospace;
    178175}
    179176ul.ind, ul.ind ul {
    180177  list-style: none;
    181178  margin-left: 1.5em;
    182   margin-right: 0em;
    183179  padding-left: 0em;
    184180  page-break-before: avoid;
    … …  
    188184  line-height: 200%;
    189185  margin-left: 0em;
    190   margin-right: 0em;
    191186}
    192187ul.ind li li {
    … …  
    194189  line-height: 150%;
    195190  margin-left: 0em;
    196   margin-right: 0em;
    197191}
    198192.avoidbreak {
    … …  
    218212  font-weight: bold;
    219213  text-align: center;
    220   font-size: 9pt;
     214  font-size: 10pt;
    221215}
    222216.filename {
    223217  color: #333333;
     218  font-size: 75%;
    224219  font-weight: bold;
    225   font-size: 12pt;
    226220  line-height: 21pt;
    227221  text-align: center;
    … …  
    230224  font-weight: bold;
    231225}
    232 .hidden {
    233   display: none;
    234 }
    235226.left {
    236227  text-align: left;
    … …  
    240231}
    241232.title {
    242   color: #990000;
    243   font-size: 18pt;
     233  color: green;
     234  font-size: 150%;
    244235  line-height: 18pt;
    245236  font-weight: bold;
    … …  
    247238  margin-top: 36pt;
    248239}
    249 .vcardline {
    250   display: block;
    251 }
    252240.warning {
    253   font-size: 14pt;
     241  font-size: 130%;
    254242  background-color: yellow;
    255243}
    … …  
    260248    display: none;
    261249  }
    262  
     250
    263251  a {
    264252    color: black;
    … …  
    275263    background-color: white;
    276264    vertical-align: top;
    277     font-size: 12pt;
    278   }
    279 
    280   ul.toc a::after {
     265    font-size: 110%;
     266  }
     267
     268  ul.toc a:nth-child(2)::after {
    281269    content: leader('.') target-counter(attr(href), page);
    282270  }
    283  
     271
    284272  ul.ind li li a {
    285273    content: target-counter(attr(href), page);
    286274  }
    287  
     275
    288276  .print2col {
    289277    column-count: 2;
    … …  
    295283@page {
    296284  @top-left {
    297        content: "RFC 2818"; 
    298   } 
     285       content: "RFC 2818";
     286  }
    299287  @top-right {
    300        content: "May 2000"; 
    301   } 
     288       content: "May 2000";
     289  }
    302290  @top-center {
    303        content: "HTTP Over TLS"; 
    304   } 
     291       content: "HTTP Over TLS";
     292  }
    305293  @bottom-left {
    306        content: "Rescorla"; 
    307   } 
     294       content: "Rescorla";
     295  }
    308296  @bottom-center {
    309        content: "Informational"; 
    310   } 
     297       content: "Informational";
     298  }
    311299  @bottom-right {
    312        content: "[Page " counter(page) "]"; 
    313   } 
    314 }
    315 
    316 @page:first { 
     300       content: "[Page " counter(page) "]";
     301  }
     302}
     303
     304@page:first {
    317305    @top-left {
    318306      content: normal;
    … …  
    337325      <link rel="Help" title="RFC-Editor's Status Page" href="http://www.rfc-editor.org/info/rfc2818">
    338326      <link rel="Help" title="Additional Information on tools.ietf.org" href="http://tools.ietf.org/html/rfc2818">
    339       <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.550, 2011-05-30 14:02:12, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
     327      <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.611, 2013/11/27 12:23:51, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
    340328      <link rel="schema.dct" href="http://purl.org/dc/terms/">
    341329      <meta name="dct.creator" content="Rescorla, E.">
    … …  
    364352      </table>
    365353      <p class="title">HTTP Over TLS</p>
    366       <h1><a id="rfc.status" href="#rfc.status">Status of This Memo</a></h1>
    367       <p>This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution
    368          of this memo is unlimited.
    369       </p>
    370       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    371       <p>Copyright © The Internet Society (2000). All Rights Reserved.</p>
    372       <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
     354      <div id="rfc.status">
     355         <h1><a href="#rfc.status">Status of This Memo</a></h1>
     356         <p>This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution
     357            of this memo is unlimited.
     358         </p>
     359      </div>
     360      <div id="rfc.copyrightnotice">
     361         <h1><a href="#rfc.copyrightnotice">Copyright Notice</a></h1>
     362         <p>Copyright © The Internet Society (2000). All Rights Reserved.</p>
     363      </div>
     364      <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
    373365      <p>This memo describes how to use TLS to secure HTTP connections over the Internet. Current practice is to layer HTTP over SSL
    374366         (the predecessor to TLS), distinguishing secured traffic from insecure traffic by the use of a different server port. This
    375367         document documents that practice using TLS. A companion document describes a method for using HTTP/TLS over the same port
    376368         as normal HTTP [RFC2817].
    377       </p> 
     369      </p>
    378370      <hr class="noprint">
    379371      <h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1>
    380372      <ul class="toc">
    381          <li>1.&nbsp;&nbsp;&nbsp;<a href="#rfc.section.1">Introduction</a><ul>
    382                <li>1.1&nbsp;&nbsp;&nbsp;<a href="#rfc.section.1.1">Requirements Terminology</a></li>
     373         <li><a href="#rfc.section.1">1.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.1">Introduction</a><ul>
     374               <li><a href="#rfc.section.1.1">1.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.1.1">Requirements Terminology</a></li>
    383375            </ul>
    384376         </li>
    385          <li>2.&nbsp;&nbsp;&nbsp;<a href="#rfc.section.2">HTTP Over TLS</a><ul>
    386                <li>2.1&nbsp;&nbsp;&nbsp;<a href="#rfc.section.2.1">Connection Initiation</a></li>
    387                <li>2.2&nbsp;&nbsp;&nbsp;<a href="#rfc.section.2.2">Connection Closure</a><ul>
    388                      <li>2.2.1&nbsp;&nbsp;&nbsp;<a href="#rfc.section.2.2.1">Client Behavior</a></li>
    389                      <li>2.2.2&nbsp;&nbsp;&nbsp;<a href="#rfc.section.2.2.2">Server Behavior</a></li>
     377         <li><a href="#rfc.section.2">2.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.2">HTTP Over TLS</a><ul>
     378               <li><a href="#rfc.section.2.1">2.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.2.1">Connection Initiation</a></li>
     379               <li><a href="#rfc.section.2.2">2.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.2.2">Connection Closure</a><ul>
     380                     <li><a href="#rfc.section.2.2.1">2.2.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.2.2.1">Client Behavior</a></li>
     381                     <li><a href="#rfc.section.2.2.2">2.2.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.2.2.2">Server Behavior</a></li>
    390382                  </ul>
    391383               </li>
    392                <li>2.3&nbsp;&nbsp;&nbsp;<a href="#rfc.section.2.3">Port Number</a></li>
    393                <li>2.4&nbsp;&nbsp;&nbsp;<a href="#rfc.section.2.4">URI Format</a></li>
     384               <li><a href="#rfc.section.2.3">2.3</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.2.3">Port Number</a></li>
     385               <li><a href="#rfc.section.2.4">2.4</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.2.4">URI Format</a></li>
    394386            </ul>
    395387         </li>
    396          <li>3.&nbsp;&nbsp;&nbsp;<a href="#rfc.section.3">Endpoint Identification</a><ul>
    397                <li>3.1&nbsp;&nbsp;&nbsp;<a href="#rfc.section.3.1">Server Identity</a></li>
    398                <li>3.2&nbsp;&nbsp;&nbsp;<a href="#rfc.section.3.2">Client Identity</a></li>
     388         <li><a href="#rfc.section.3">3.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.3">Endpoint Identification</a><ul>
     389               <li><a href="#rfc.section.3.1">3.1</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.3.1">Server Identity</a></li>
     390               <li><a href="#rfc.section.3.2">3.2</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.3.2">Client Identity</a></li>
    399391            </ul>
    400392         </li>
    401          <li>4.&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a></li>
     393         <li><a href="#rfc.section.4">4.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a></li>
    402394         <li><a href="#rfc.authors">Author's Address</a></li>
    403          <li>A.&nbsp;&nbsp;&nbsp;<a href="#rfc.section.A">Security Considerations</a></li>
     395         <li><a href="#rfc.section.A">A.</a>&nbsp;&nbsp;&nbsp;<a href="#rfc.section.A">Security Considerations</a></li>
    404396         <li><a href="#rfc.index">Index</a></li>
    405397         <li><a href="#rfc.ipr">Intellectual Property and Copyright Statements</a></li>
    406398      </ul>
    407       <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;Introduction
    408       </h1>
    409       <p id="rfc.section.1.p.1">HTTP <a href="#RFC2616"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a> was originally used in the clear on the Internet. However, increased use of HTTP for sensitive applications has required security
    410          measures. SSL, and its successor TLS <a href="#RFC2246"><cite title="The TLS Protocol Version 1.0">[RFC2246]</cite></a> were designed to provide channel-oriented security. This document describes how to use HTTP over TLS.
    411       </p>
    412       <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;Requirements Terminology
    413       </h2>
    414       <p id="rfc.section.1.1.p.1">Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be interpreted
    415          as described in <a href="#RFC2119"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.
    416       </p>
    417       <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;HTTP Over TLS
    418       </h1>
    419       <p id="rfc.section.2.p.1">Conceptually, HTTP/TLS is very simple. Simply use HTTP over TLS precisely as you would use HTTP over TCP.</p>
    420       <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;Connection Initiation
    421       </h2>
    422       <p id="rfc.section.2.1.p.1">The agent acting as the HTTP client should also act as the TLS client. It should initiate a connection to the server on the
    423          appropriate port and then send the TLS ClientHello to begin the TLS handshake. When the TLS handshake has finished. The client
    424          may then initiate the first HTTP request. All HTTP data <em class="bcp14">MUST</em> be sent as TLS "application data". Normal HTTP behavior, including retained connections should be followed.
    425       </p>
    426       <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;Connection Closure
    427       </h2>
    428       <p id="rfc.section.2.2.p.1">TLS provides a facility for secure connection closure. When a valid closure alert is received, an implementation can be assured
    429          that no further data will be received on that connection. TLS implementations <em class="bcp14">MUST</em> initiate an exchange of closure alerts before closing a connection. A TLS implementation <em class="bcp14">MAY</em>, after sending a closure alert, close the connection without waiting for the peer to send its closure alert, generating an
    430          "incomplete close". Note that an implementation which does this <em class="bcp14">MAY</em> choose to reuse the session. This <em class="bcp14">SHOULD</em> only be done when the application knows (typically through detecting HTTP message boundaries) that it has received all the
    431          message data that it cares about.
    432       </p>
    433       <p id="rfc.section.2.2.p.2">As specified in <a href="#RFC2246"><cite title="The TLS Protocol Version 1.0">[RFC2246]</cite></a>, any implementation which receives a connection close without first receiving a valid closure alert (a "premature close") <em class="bcp14">MUST NOT</em> reuse that session. Note that a premature close does not call into question the security of the data already received, but
    434          simply indicates that subsequent data might have been truncated. Because TLS is oblivious to HTTP request/response boundaries,
    435          it is necessary to examine the HTTP data itself (specifically the Content-Length header) to determine whether the truncation
    436          occurred inside a message or between messages.
    437       </p>
    438       <h3 id="rfc.section.2.2.1"><a href="#rfc.section.2.2.1">2.2.1</a>&nbsp;Client Behavior
    439       </h3>
    440       <p id="rfc.section.2.2.1.p.1">Because HTTP uses connection closure to signal end of server data, client implementations <em class="bcp14">MUST</em> treat any premature closes as errors and the data received as potentially truncated. While in some cases the HTTP protocol
    441          allows the client to find out whether truncation took place so that, if it received the complete reply, it may tolerate such
    442          errors following the principle to "[be] strict when sending and tolerant when receiving" [RFC1958], often truncation does
    443          not show in the HTTP protocol data; two cases in particular deserve special note:
    444       </p>
    445       <ul class="empty">
    446          <li>A HTTP response without a Content-Length header. Since data length in this situation is signalled by connection close a premature
    447             close generated by the server cannot be distinguished from a spurious close generated by an attacker.
    448          </li>
    449          <li>A HTTP response with a valid Content-Length header closed before all data has been read. Because TLS does not provide document
    450             oriented protection, it is impossible to determine whether the server has miscomputed the Content-Length or an attacker has
    451             truncated the connection.
    452          </li>
    453       </ul>
    454       <p id="rfc.section.2.2.1.p.3">There is one exception to the above rule. When encountering a premature close, a client <em class="bcp14">SHOULD</em> treat as completed all requests for which it has received as much data as specified in the Content-Length header.
    455       </p>
    456       <p id="rfc.section.2.2.1.p.4">A client detecting an incomplete close <em class="bcp14">SHOULD</em> recover gracefully. It <em class="bcp14">MAY</em> resume a TLS session closed in this fashion.
    457       </p>
    458       <p id="rfc.section.2.2.1.p.5">Clients <em class="bcp14">MUST</em> send a closure alert before closing the connection. Clients which are unprepared to receive any more data <em class="bcp14">MAY</em> choose not to wait for the server's closure alert and simply close the connection, thus generating an incomplete close on
    459          the server side.
    460       </p>
    461       <h3 id="rfc.section.2.2.2"><a href="#rfc.section.2.2.2">2.2.2</a>&nbsp;Server Behavior
    462       </h3>
    463       <p id="rfc.section.2.2.2.p.1">RFC 2616 permits an HTTP client to close the connection at any time, and requires servers to recover gracefully. In particular,
    464          servers <em class="bcp14">SHOULD</em> be prepared to receive an incomplete close from the client, since the client can often determine when the end of server data
    465          is. Servers <em class="bcp14">SHOULD</em> be willing to resume TLS sessions closed in this fashion.
    466       </p>
    467       <p id="rfc.section.2.2.2.p.2">Implementation note: In HTTP implementations which do not use persistent connections, the server ordinarily expects to be
    468          able to signal end of data by closing the connection. When Content-Length is used, however, the client may have already sent
    469          the closure alert and dropped the connection.
    470       </p>
    471       <p id="rfc.section.2.2.2.p.3">Servers <em class="bcp14">MUST</em> attempt to initiate an exchange of closure alerts with the client before closing the connection. Servers <em class="bcp14">MAY</em> close the connection after sending the closure alert, thus generating an incomplete close on the client side.
    472       </p>
    473       <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;Port Number
    474       </h2>
    475       <p id="rfc.section.2.3.p.1">The first data that an HTTP server expects to receive from the client is the Request-Line production. The first data that
    476          a TLS server (and hence an HTTP/TLS server) expects to receive is the ClientHello. Consequently, common practice has been
    477          to run HTTP/TLS over a separate port in order to distinguish which protocol is being used. When HTTP/TLS is being run over
    478          a TCP/IP connection, the default port is 443. This does not preclude HTTP/TLS from being run over another transport. TLS only
    479          presumes a reliable connection-oriented data stream.
    480       </p>
    481       <div id="rfc.iref.h.1"></div>
    482       <div id="rfc.iref.u.1"></div>
    483       <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;URI Format
    484       </h2>
    485       <p id="rfc.section.2.4.p.1">HTTP/TLS is differentiated from HTTP URIs by using the 'https' protocol identifier in place of the 'http' protocol identifier.
    486          An example URI specifying HTTP/TLS is:
    487       </p>
    488       <div id="rfc.figure.u.1"></div><pre class="text">
     399      <div>
     400         <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;Introduction
     401         </h1>
     402         <p id="rfc.section.1.p.1">HTTP <a href="#RFC2616"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a> was originally used in the clear on the Internet. However, increased use of HTTP for sensitive applications has required security
     403            measures. SSL, and its successor TLS <a href="#RFC2246"><cite title="The TLS Protocol Version 1.0">[RFC2246]</cite></a> were designed to provide channel-oriented security. This document describes how to use HTTP over TLS.
     404         </p>
     405         <div>
     406            <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;Requirements Terminology
     407            </h2>
     408            <p id="rfc.section.1.1.p.1">Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be interpreted
     409               as described in <a href="#RFC2119"><cite title="Key words for use in RFCs to Indicate Requirement Levels">[RFC2119]</cite></a>.
     410            </p>
     411         </div>
     412      </div>
     413      <div>
     414         <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;HTTP Over TLS
     415         </h1>
     416         <p id="rfc.section.2.p.1">Conceptually, HTTP/TLS is very simple. Simply use HTTP over TLS precisely as you would use HTTP over TCP.</p>
     417         <div>
     418            <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;Connection Initiation
     419            </h2>
     420            <p id="rfc.section.2.1.p.1">The agent acting as the HTTP client should also act as the TLS client. It should initiate a connection to the server on the
     421               appropriate port and then send the TLS ClientHello to begin the TLS handshake. When the TLS handshake has finished. The client
     422               may then initiate the first HTTP request. All HTTP data <em class="bcp14">MUST</em> be sent as TLS "application data". Normal HTTP behavior, including retained connections should be followed.
     423            </p>
     424         </div>
     425         <div>
     426            <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;Connection Closure
     427            </h2>
     428            <p id="rfc.section.2.2.p.1">TLS provides a facility for secure connection closure. When a valid closure alert is received, an implementation can be assured
     429               that no further data will be received on that connection. TLS implementations <em class="bcp14">MUST</em> initiate an exchange of closure alerts before closing a connection. A TLS implementation <em class="bcp14">MAY</em>, after sending a closure alert, close the connection without waiting for the peer to send its closure alert, generating an
     430               "incomplete close". Note that an implementation which does this <em class="bcp14">MAY</em> choose to reuse the session. This <em class="bcp14">SHOULD</em> only be done when the application knows (typically through detecting HTTP message boundaries) that it has received all the
     431               message data that it cares about.
     432            </p>
     433            <p id="rfc.section.2.2.p.2">As specified in <a href="#RFC2246"><cite title="The TLS Protocol Version 1.0">[RFC2246]</cite></a>, any implementation which receives a connection close without first receiving a valid closure alert (a "premature close") <em class="bcp14">MUST NOT</em> reuse that session. Note that a premature close does not call into question the security of the data already received, but
     434               simply indicates that subsequent data might have been truncated. Because TLS is oblivious to HTTP request/response boundaries,
     435               it is necessary to examine the HTTP data itself (specifically the Content-Length header) to determine whether the truncation
     436               occurred inside a message or between messages.
     437            </p>
     438            <div>
     439               <h3 id="rfc.section.2.2.1"><a href="#rfc.section.2.2.1">2.2.1</a>&nbsp;Client Behavior
     440               </h3>
     441               <p id="rfc.section.2.2.1.p.1">Because HTTP uses connection closure to signal end of server data, client implementations <em class="bcp14">MUST</em> treat any premature closes as errors and the data received as potentially truncated. While in some cases the HTTP protocol
     442                  allows the client to find out whether truncation took place so that, if it received the complete reply, it may tolerate such
     443                  errors following the principle to "[be] strict when sending and tolerant when receiving" [RFC1958], often truncation does
     444                  not show in the HTTP protocol data; two cases in particular deserve special note:
     445               </p>
     446               <ul class="empty">
     447                  <li>A HTTP response without a Content-Length header. Since data length in this situation is signalled by connection close a premature
     448                     close generated by the server cannot be distinguished from a spurious close generated by an attacker.
     449                  </li>
     450                  <li>A HTTP response with a valid Content-Length header closed before all data has been read. Because TLS does not provide document
     451                     oriented protection, it is impossible to determine whether the server has miscomputed the Content-Length or an attacker has
     452                     truncated the connection.
     453                  </li>
     454               </ul>
     455               <p id="rfc.section.2.2.1.p.3">There is one exception to the above rule. When encountering a premature close, a client <em class="bcp14">SHOULD</em> treat as completed all requests for which it has received as much data as specified in the Content-Length header.
     456               </p>
     457               <p id="rfc.section.2.2.1.p.4">A client detecting an incomplete close <em class="bcp14">SHOULD</em> recover gracefully. It <em class="bcp14">MAY</em> resume a TLS session closed in this fashion.
     458               </p>
     459               <p id="rfc.section.2.2.1.p.5">Clients <em class="bcp14">MUST</em> send a closure alert before closing the connection. Clients which are unprepared to receive any more data <em class="bcp14">MAY</em> choose not to wait for the server's closure alert and simply close the connection, thus generating an incomplete close on
     460                  the server side.
     461               </p>
     462            </div>
     463            <div>
     464               <h3 id="rfc.section.2.2.2"><a href="#rfc.section.2.2.2">2.2.2</a>&nbsp;Server Behavior
     465               </h3>
     466               <p id="rfc.section.2.2.2.p.1">RFC 2616 permits an HTTP client to close the connection at any time, and requires servers to recover gracefully. In particular,
     467                  servers <em class="bcp14">SHOULD</em> be prepared to receive an incomplete close from the client, since the client can often determine when the end of server data
     468                  is. Servers <em class="bcp14">SHOULD</em> be willing to resume TLS sessions closed in this fashion.
     469               </p>
     470               <p id="rfc.section.2.2.2.p.2">Implementation note: In HTTP implementations which do not use persistent connections, the server ordinarily expects to be
     471                  able to signal end of data by closing the connection. When Content-Length is used, however, the client may have already sent
     472                  the closure alert and dropped the connection.
     473               </p>
     474               <p id="rfc.section.2.2.2.p.3">Servers <em class="bcp14">MUST</em> attempt to initiate an exchange of closure alerts with the client before closing the connection. Servers <em class="bcp14">MAY</em> close the connection after sending the closure alert, thus generating an incomplete close on the client side.
     475               </p>
     476            </div>
     477         </div>
     478         <div>
     479            <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;Port Number
     480            </h2>
     481            <p id="rfc.section.2.3.p.1">The first data that an HTTP server expects to receive from the client is the Request-Line production. The first data that
     482               a TLS server (and hence an HTTP/TLS server) expects to receive is the ClientHello. Consequently, common practice has been
     483               to run HTTP/TLS over a separate port in order to distinguish which protocol is being used. When HTTP/TLS is being run over
     484               a TCP/IP connection, the default port is 443. This does not preclude HTTP/TLS from being run over another transport. TLS only
     485               presumes a reliable connection-oriented data stream.
     486            </p>
     487         </div>
     488         <div>
     489            <div id="rfc.iref.h.1"></div>
     490            <div id="rfc.iref.u.1"></div>
     491            <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;URI Format
     492            </h2>
     493            <p id="rfc.section.2.4.p.1">HTTP/TLS is differentiated from HTTP URIs by using the 'https' protocol identifier in place of the 'http' protocol identifier.
     494               An example URI specifying HTTP/TLS is:
     495            </p>
     496            <div id="rfc.figure.u.1"></div><pre class="text">
    489497  https://www.example.com/~smith/home.html
    490 </pre><h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;Endpoint Identification
    491       </h1>
    492       <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;Server Identity
    493       </h2>
    494       <p id="rfc.section.3.1.p.1">In general, HTTP/TLS requests are generated by dereferencing a URI. As a consequence, the hostname for the server is known
    495          to the client. If the hostname is available, the client <em class="bcp14">MUST</em> check it against the server's identity as presented in the server's Certificate message, in order to prevent man-in-the-middle
    496          attacks.
    497       </p>
    498       <p id="rfc.section.3.1.p.2">If the client has external information as to the expected identity of the server, the hostname check <em class="bcp14">MAY</em> be omitted. (For instance, a client may be connecting to a machine whose address and hostname are dynamic but the client knows
    499          the certificate that the server will present.) In such cases, it is important to narrow the scope of acceptable certificates
    500          as much as possible in order to prevent man in the middle attacks. In special cases, it may be appropriate for the client
    501          to simply ignore the server's identity, but it must be understood that this leaves the connection open to active attack.
    502       </p>
    503       <p id="rfc.section.3.1.p.3">If a subjectAltName extension of type dNSName is present, that <em class="bcp14">MUST</em> be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate <em class="bcp14">MUST</em> be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged
    504          to use the dNSName instead.
    505       </p>
    506       <p id="rfc.section.3.1.p.4">Matching is performed using the matching rules specified by <a href="#RFC2459"><cite title="Internet X.509 Public Key Infrastructure Certificate and CRL Profile">[RFC2459]</cite></a>. If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name, a match in any
    507          one of the set is considered acceptable.) Names may contain the wildcard character * which is considered to match any single
    508          domain name component or component fragment. E.g., *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com
    509          but not bar.com.
    510       </p>
    511       <p id="rfc.section.3.1.p.5">In some cases, the URI is specified as an IP address rather than a hostname. In this case, the iPAddress subjectAltName must
    512          be present in the certificate and must exactly match the IP in the URI.
    513       </p>
    514       <p id="rfc.section.3.1.p.6">If the hostname does not match the identity in the certificate, user oriented clients <em class="bcp14">MUST</em> either notify the user (clients <em class="bcp14">MAY</em> give the user the opportunity to continue with the connection in any case) or terminate the connection with a bad certificate
    515          error. Automated clients <em class="bcp14">MUST</em> log the error to an appropriate audit log (if available) and <em class="bcp14">SHOULD</em> terminate the connection (with a bad certificate error). Automated clients <em class="bcp14">MAY</em> provide a configuration setting that disables this check, but <em class="bcp14">MUST</em> provide a setting which enables it.
    516       </p>
    517       <p id="rfc.section.3.1.p.7">Note that in many cases the URI itself comes from an untrusted source. The above-described check provides no protection against
    518          attacks where this source is compromised. For example, if the URI was obtained by clicking on an HTML page which was itself
    519          obtained without using HTTP/TLS, a man in the middle could have replaced the URI. In order to prevent this form of attack,
    520          users should carefully examine the certificate presented by the server to determine if it meets their expectations.
    521       </p>
    522       <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;Client Identity
    523       </h2>
    524       <p id="rfc.section.3.2.p.1">Typically, the server has no external knowledge of what the client's identity ought to be and so checks (other than that the
    525          client has a certificate chain rooted in an appropriate CA) are not possible. If a server has such knowledge (typically from
    526          some source external to HTTP or TLS) it <em class="bcp14">SHOULD</em> check the identity as described above.
    527       </p>
     498</pre></div>
     499      </div>
     500      <div>
     501         <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;Endpoint Identification
     502         </h1>
     503         <div>
     504            <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;Server Identity
     505            </h2>
     506            <p id="rfc.section.3.1.p.1">In general, HTTP/TLS requests are generated by dereferencing a URI. As a consequence, the hostname for the server is known
     507               to the client. If the hostname is available, the client <em class="bcp14">MUST</em> check it against the server's identity as presented in the server's Certificate message, in order to prevent man-in-the-middle
     508               attacks.
     509            </p>
     510            <p id="rfc.section.3.1.p.2">If the client has external information as to the expected identity of the server, the hostname check <em class="bcp14">MAY</em> be omitted. (For instance, a client may be connecting to a machine whose address and hostname are dynamic but the client knows
     511               the certificate that the server will present.) In such cases, it is important to narrow the scope of acceptable certificates
     512               as much as possible in order to prevent man in the middle attacks. In special cases, it may be appropriate for the client
     513               to simply ignore the server's identity, but it must be understood that this leaves the connection open to active attack.
     514            </p>
     515            <p id="rfc.section.3.1.p.3">If a subjectAltName extension of type dNSName is present, that <em class="bcp14">MUST</em> be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate <em class="bcp14">MUST</em> be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged
     516               to use the dNSName instead.
     517            </p>
     518            <p id="rfc.section.3.1.p.4">Matching is performed using the matching rules specified by <a href="#RFC2459"><cite title="Internet X.509 Public Key Infrastructure Certificate and CRL Profile">[RFC2459]</cite></a>. If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name, a match in any
     519               one of the set is considered acceptable.) Names may contain the wildcard character * which is considered to match any single
     520               domain name component or component fragment. E.g., *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com
     521               but not bar.com.
     522            </p>
     523            <p id="rfc.section.3.1.p.5">In some cases, the URI is specified as an IP address rather than a hostname. In this case, the iPAddress subjectAltName must
     524               be present in the certificate and must exactly match the IP in the URI.
     525            </p>
     526            <p id="rfc.section.3.1.p.6">If the hostname does not match the identity in the certificate, user oriented clients <em class="bcp14">MUST</em> either notify the user (clients <em class="bcp14">MAY</em> give the user the opportunity to continue with the connection in any case) or terminate the connection with a bad certificate
     527               error. Automated clients <em class="bcp14">MUST</em> log the error to an appropriate audit log (if available) and <em class="bcp14">SHOULD</em> terminate the connection (with a bad certificate error). Automated clients <em class="bcp14">MAY</em> provide a configuration setting that disables this check, but <em class="bcp14">MUST</em> provide a setting which enables it.
     528            </p>
     529            <p id="rfc.section.3.1.p.7">Note that in many cases the URI itself comes from an untrusted source. The above-described check provides no protection against
     530               attacks where this source is compromised. For example, if the URI was obtained by clicking on an HTML page which was itself
     531               obtained without using HTTP/TLS, a man in the middle could have replaced the URI. In order to prevent this form of attack,
     532               users should carefully examine the certificate presented by the server to determine if it meets their expectations.
     533            </p>
     534         </div>
     535         <div>
     536            <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;Client Identity
     537            </h2>
     538            <p id="rfc.section.3.2.p.1">Typically, the server has no external knowledge of what the client's identity ought to be and so checks (other than that the
     539               client has a certificate chain rooted in an appropriate CA) are not possible. If a server has such knowledge (typically from
     540               some source external to HTTP or TLS) it <em class="bcp14">SHOULD</em> check the identity as described above.
     541            </p>
     542         </div>
     543      </div>
    528544      <h1 id="rfc.references"><a href="#rfc.section.4" id="rfc.section.4">4.</a> References
    529545      </h1>
    530       <table> 
     546      <table>
    531547         <tr>
    532548            <td class="reference"><b id="RFC2459">[RFC2459]</b></td>
    533549            <td class="top"><a href="mailto:housley@spyrus.com" title="SPYRUS">Housley, R.</a>, <a href="mailto:wford@verisign.com" title="VeriSign, Inc.">Ford, W.</a>, <a href="mailto:wpolk@nist.gov" title="NIST">Polk, T.</a>, and <a href="mailto:david.solo@citicorp.com" title="Citicorp">D. Solo</a>, “<a href="http://tools.ietf.org/html/rfc2459">Internet X.509 Public Key Infrastructure Certificate and CRL Profile</a>”, RFC&nbsp;2459, January&nbsp;1999.
    534550            </td>
    535          </tr> 
     551         </tr>
    536552         <tr>
    537553            <td class="reference"><b id="RFC2616">[RFC2616]</b></td>
    538554            <td class="top"><a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine">Fielding, R.</a>, <a href="mailto:jg@w3.org" title="W3C">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com" title="Compaq Computer Corporation">Mogul, J.</a>, <a href="mailto:frystyk@w3.org" title="MIT Laboratory for Computer Science">Frystyk, H.</a>, <a href="mailto:masinter@parc.xerox.com" title="Xerox Corporation">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, and <a href="mailto:timbl@w3.org" title="W3C">T. Berners-Lee</a>, “<a href="http://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC&nbsp;2616, June&nbsp;1999.
    539555            </td>
    540          </tr> 
     556         </tr>
    541557         <tr>
    542558            <td class="reference"><b id="RFC2119">[RFC2119]</b></td>
    543559            <td class="top"><a href="mailto:sob@harvard.edu" title="Harvard University">Bradner, S.</a>, “<a href="http://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>”, BCP&nbsp;14, RFC&nbsp;2119, March&nbsp;1997.
    544560            </td>
    545          </tr> 
     561         </tr>
    546562         <tr>
    547563            <td class="reference"><b id="RFC2246">[RFC2246]</b></td>
    548564            <td class="top"><a href="mailto:tdierks@certicom.com" title="Certicom">Dierks, T.</a> and <a href="mailto:callen@certicom.com" title="Certicom">C. Allen</a>, “<a href="http://tools.ietf.org/html/rfc2246">The TLS Protocol Version 1.0</a>”, RFC&nbsp;2246, January&nbsp;1999.
    549565            </td>
    550          </tr> 
     566         </tr>
    551567         <tr>
    552568            <td class="reference"><b id="RFC2817">[RFC2817]</b></td>
    553569            <td class="top">Khare, R. and S. Lawrence, “<a href="http://tools.ietf.org/html/rfc2817">Upgrading to TLS Within HTTP/1.1</a>”, RFC&nbsp;2817, May&nbsp;2000.
    554570            </td>
    555          </tr> 
     571         </tr>
    556572      </table>
    557573      <div class="avoidbreak">
    558574         <h1 id="rfc.authors"><a href="#rfc.authors">Author's Address</a></h1>
    559          <address class="vcard"><span class="vcardline"><span class="fn">Eric Rescorla</span><span class="n hidden"><span class="family-name">Rescorla</span><span class="given-name">Eric</span></span></span><span class="org vcardline">RTFM, Inc.</span><span class="adr"><span class="street-address vcardline">30 Newell Road, #16</span><span class="vcardline"><span class="locality">East Palo Alto</span>, <span class="region">CA</span>&nbsp;<span class="postal-code">94303</span></span></span><span class="vcardline tel">Phone: <a href="tel:(650)328-8631"><span class="value">(650) 328-8631</span></a></span><span class="vcardline">Email: <a href="mailto:ekr@rtfm.com"><span class="email">ekr@rtfm.com</span></a></span></address>
    560       </div>
    561       <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;Security Considerations
    562       </h1>
    563       <p id="rfc.section.A.p.1">This entire document is about security.</p>
     575         <p><b>Eric Rescorla</b><br>RTFM, Inc.<br>30 Newell Road, #16<br>East Palo Alto, CA&nbsp;94303<br>Phone: <a href="tel:(650)328-8631">(650) 328-8631</a><br>Email: <a href="mailto:ekr@rtfm.com">ekr@rtfm.com</a></p>
     576      </div>
     577      <div>
     578         <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;Security Considerations
     579         </h1>
     580         <p id="rfc.section.A.p.1">This entire document is about security.</p>
     581      </div>
    564582      <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1>
    565583      <p class="noprint"><a href="#rfc.index.H">H</a> <a href="#rfc.index.U">U</a>
    … …  
    581599         </ul>
    582600      </div>
    583       <h1><a id="rfc.copyright" href="#rfc.copyright">Full Copyright Statement</a></h1>
    584       <p>Copyright © The Internet Society (2000). All Rights Reserved.</p>
    585       <p>This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise
    586          explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without
    587          restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative
    588          works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references
    589          to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards
    590          in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to
    591          translate it into languages other than English.
    592       </p>
    593       <p>The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.</p>
    594       <p>This document and the information contained herein is provided on an “AS IS” basis and THE INTERNET SOCIETY AND THE INTERNET
    595          ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
    596          OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
    597          PURPOSE.
    598       </p>
    599       <h1><a id="rfc.ipr" href="#rfc.ipr">Intellectual Property</a></h1>
    600       <p>The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed
    601          to pertain to the implementation or use of the technology described in this document or the extent to which any license under
    602          such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights.
    603          Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be
    604          found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available,
    605          or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors
    606          or users of this specification can be obtained from the IETF Secretariat.
    607       </p>
    608       <p>The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary
    609          rights which may cover technology that may be required to practice this standard. Please address the information to the IETF
    610          Executive Director.
    611       </p>
    612       <h1>Acknowledgement</h1>
    613       <p>Funding for the RFC Editor function is currently provided by the Internet Society.</p>
     601      <div id="rfc.copyright">
     602         <h1><a href="#rfc.copyright">Full Copyright Statement</a></h1>
     603         <p>Copyright © The Internet Society (2000). All Rights Reserved.</p>
     604         <p>This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise
     605            explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without
     606            restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative
     607            works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references
     608            to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards
     609            in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to
     610            translate it into languages other than English.
     611         </p>
     612         <p>The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.</p>
     613         <p>This document and the information contained herein is provided on an “AS IS” basis and THE INTERNET SOCIETY AND THE INTERNET
     614            ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
     615            OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
     616            PURPOSE.
     617         </p>
     618      </div>
     619      <div id="rfc.ipr">
     620         <h1><a href="#rfc.ipr">Intellectual Property</a></h1>
     621         <p>The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed
     622            to pertain to the implementation or use of the technology described in this document or the extent to which any license under
     623            such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights.
     624            Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be
     625            found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available,
     626            or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors
     627            or users of this specification can be obtained from the IETF Secretariat.
     628         </p>
     629         <p>The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary
     630            rights which may cover technology that may be required to practice this standard. Please address the information to the IETF
     631            Executive Director.
     632         </p>
     633      </div>
     634      <div>
     635         <h1>Acknowledgement</h1>
     636         <p>Funding for the RFC Editor function is currently provided by the Internet Society.</p>
     637      </div>
    614638   </body>
    615639</html>
Note: See TracChangeset for help on using the changeset viewer.