Changeset 1588
- Timestamp:
- 12/03/12 08:19:08 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1586 r1588 460 460 } 461 461 @bottom-center { 462 content: "Expires September 1 2, 2012";462 content: "Expires September 13, 2012"; 463 463 } 464 464 @bottom-right { … … 502 502 <meta name="dct.creator" content="Reschke, J. F."> 503 503 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 504 <meta name="dct.issued" scheme="ISO8601" content="2012-03-1 1">504 <meta name="dct.issued" scheme="ISO8601" content="2012-03-12"> 505 505 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 506 506 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> … … 534 534 </tr> 535 535 <tr> 536 <td class="left">Expires: September 1 2, 2012</td>536 <td class="left">Expires: September 13, 2012</td> 537 537 <td class="right">greenbytes</td> 538 538 </tr> 539 539 <tr> 540 540 <td class="left"></td> 541 <td class="right">March 1 1, 2012</td>541 <td class="right">March 12, 2012</td> 542 542 </tr> 543 543 </tbody> … … 572 572 in progress”. 573 573 </p> 574 <p>This Internet-Draft will expire on September 1 2, 2012.</p>574 <p>This Internet-Draft will expire on September 13, 2012.</p> 575 575 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 576 576 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 706 706 <li>8.3 <a href="#attack.pathname">Attacks Based On File and Path Names</a></li> 707 707 <li>8.4 <a href="#dns.related.attacks">DNS-related Attacks</a></li> 708 <li>8.5 <a href="#attack. proxies">Proxies and Caching</a></li>708 <li>8.5 <a href="#attack.intermediaries">Intermediaries and Caching</a></li> 709 709 <li>8.6 <a href="#attack.protocol.element.size.overflows">Protocol Element Size Overflows</a></li> 710 <li>8.7 <a href="#attack.DoS">Denial of Service Attacks on Proxies</a></li>711 710 </ul> 712 711 </li> … … 2643 2642 <h2 id="rfc.section.8.2"><a href="#rfc.section.8.2">8.2</a> <a id="abuse.of.server.log.information" href="#abuse.of.server.log.information">Abuse of Server Log Information</a></h2> 2644 2643 <p id="rfc.section.8.2.p.1">A server is in the position to save personal data about a user's requests which might identify their reading patterns or subjects 2645 of interest. This information is clearly confidential in nature and its handling can be constrained by law in certain countries. 2646 People using HTTP to provide data are responsible for ensuring that such material is not distributed without the permission 2647 of any individuals that are identifiable by the published results. 2644 of interest. In particular, log information gathered at an intermediary often contains a history of user agent interaction, 2645 across a multitude of sites, that can be traced to individual users. 2646 </p> 2647 <p id="rfc.section.8.2.p.2">HTTP log information is confidential in nature; its handling is often constrained by laws and regulations. Log information 2648 needs to be securely stored and appropriate guidelines followed for its analysis. Anonymization of personal information within 2649 individual entries helps, but is generally not sufficient to prevent real log traces from being re-identified based on correlation 2650 with other access characteristics. As such, access traces that are keyed to a specific client should not be published even 2651 if the key is pseudonymous. 2652 </p> 2653 <p id="rfc.section.8.2.p.3">To minimize the risk of theft or accidental publication, log information should be purged of personally identifiable information, 2654 including user identifiers, IP addresses, and user-provided query parameters, as soon as that information is no longer necessary 2655 to support operational needs for security, auditing, or fraud control. 2648 2656 </p> 2649 2657 <h2 id="rfc.section.8.3"><a href="#rfc.section.8.3">8.3</a> <a id="attack.pathname" href="#attack.pathname">Attacks Based On File and Path Names</a></h2> … … 2661 2669 validity of an IP number/DNS name association unless the response is protected by DNSSec (<a href="#RFC4033" id="rfc.xref.RFC4033.1"><cite title="DNS Security Introduction and Requirements">[RFC4033]</cite></a>). 2662 2670 </p> 2663 <h2 id="rfc.section.8.5"><a href="#rfc.section.8.5">8.5</a> <a id="attack.proxies" href="#attack.proxies">Proxies and Caching</a></h2> 2664 <p id="rfc.section.8.5.p.1">By their very nature, HTTP proxies are men-in-the-middle, and represent an opportunity for man-in-the-middle attacks. Compromise 2665 of the systems on which the proxies run can result in serious security and privacy problems. Proxies have access to security-related 2666 information, personal information about individual users and organizations, and proprietary information belonging to users 2667 and content providers. A compromised proxy, or a proxy implemented or configured without regard to security and privacy considerations, 2668 might be used in the commission of a wide range of potential attacks. 2669 </p> 2670 <p id="rfc.section.8.5.p.2">Proxy operators need to protect the systems on which proxies run as they would protect any system that contains or transports 2671 sensitive information. In particular, log information gathered at proxies often contains highly sensitive personal information, 2672 and/or information about organizations. Log information needs to be carefully guarded, and appropriate guidelines for use 2673 need to be developed and followed. (<a href="#abuse.of.server.log.information" title="Abuse of Server Log Information">Section 8.2</a>). 2674 </p> 2675 <p id="rfc.section.8.5.p.3">Proxy implementors need to consider the privacy and security implications of their design and coding decisions, and of the 2676 configuration options they provide to proxy operators (especially the default configuration). 2677 </p> 2678 <p id="rfc.section.8.5.p.4">Users of a proxy need to be aware that proxies are no more trustworthy than the people who run them; HTTP itself cannot solve 2671 <h2 id="rfc.section.8.5"><a href="#rfc.section.8.5">8.5</a> <a id="attack.intermediaries" href="#attack.intermediaries">Intermediaries and Caching</a></h2> 2672 <p id="rfc.section.8.5.p.1">By their very nature, HTTP intermediaries are men-in-the-middle, and represent an opportunity for man-in-the-middle attacks. 2673 Compromise of the systems on which the intermediaries run can result in serious security and privacy problems. Intermediaries 2674 have access to security-related information, personal information about individual users and organizations, and proprietary 2675 information belonging to users and content providers. A compromised intermediary, or an intermediary implemented or configured 2676 without regard to security and privacy considerations, might be used in the commission of a wide range of potential attacks. 2677 </p> 2678 <p id="rfc.section.8.5.p.2">Intermediaries that contain a shared cache are especially vulnerable to cache poisoning attacks.</p> 2679 <p id="rfc.section.8.5.p.3">Implementors need to consider the privacy and security implications of their design and coding decisions, and of the configuration 2680 options they provide to operators (especially the default configuration). 2681 </p> 2682 <p id="rfc.section.8.5.p.4">Users need to be aware that intermediaries are no more trustworthy than the people who run them; HTTP itself cannot solve 2679 2683 this problem. 2680 2684 </p> … … 2693 2697 <p id="rfc.section.8.6.p.4">Other fields (including but not limited to request methods, response status phrases, header field-names, and body chunks) <em class="bcp14">SHOULD</em> be limited by implementations carefully, so as to not impede interoperability. 2694 2698 </p> 2695 <h2 id="rfc.section.8.7"><a href="#rfc.section.8.7">8.7</a> <a id="attack.DoS" href="#attack.DoS">Denial of Service Attacks on Proxies</a></h2>2696 <p id="rfc.section.8.7.p.1">They exist. They are hard to defend against. Research continues. Beware.</p>2697 2699 <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a> <a id="acks" href="#acks">Acknowledgments</a></h1> 2698 2700 <p id="rfc.section.9.p.1">This edition of HTTP builds on the many contributions that went into <a href="#RFC1945" id="rfc.xref.RFC1945.2">RFC 1945</a>, <a href="#RFC2068" id="rfc.xref.RFC2068.5">RFC 2068</a>, <a href="#RFC2145" id="rfc.xref.RFC2145.3">RFC 2145</a>, and <a href="#RFC2616" id="rfc.xref.RFC2616.4">RFC 2616</a>, including substantial contributions made by the previous authors, editors, and working group chairs: Tim Berners-Lee, Ari -
draft-ietf-httpbis/latest/p1-messaging.xml
r1586 r1588 3706 3706 A server is in the position to save personal data about a user's 3707 3707 requests which might identify their reading patterns or subjects of 3708 interest. This information is clearly confidential in nature and its 3709 handling can be constrained by law in certain countries. People using 3710 HTTP to provide data are responsible for ensuring that 3711 such material is not distributed without the permission of any 3712 individuals that are identifiable by the published results. 3708 interest. In particular, log information gathered at an intermediary 3709 often contains a history of user agent interaction, across a multitude 3710 of sites, that can be traced to individual users. 3711 </t> 3712 <t> 3713 HTTP log information is confidential in nature; its handling is often 3714 constrained by laws and regulations. Log information needs to be securely 3715 stored and appropriate guidelines followed for its analysis. 3716 Anonymization of personal information within individual entries helps, 3717 but is generally not sufficient to prevent real log traces from being 3718 re-identified based on correlation with other access characteristics. 3719 As such, access traces that are keyed to a specific client should not 3720 be published even if the key is pseudonymous. 3721 </t> 3722 <t> 3723 To minimize the risk of theft or accidental publication, log information 3724 should be purged of personally identifiable information, including 3725 user identifiers, IP addresses, and user-provided query parameters, 3726 as soon as that information is no longer necessary to support operational 3727 needs for security, auditing, or fraud control. 3713 3728 </t> 3714 3729 </section> … … 3745 3760 </section> 3746 3761 3747 <section title=" Proxies and Caching" anchor="attack.proxies">3748 <t> 3749 By their very nature, HTTP proxies are men-in-the-middle, and3762 <section title="Intermediaries and Caching" anchor="attack.intermediaries"> 3763 <t> 3764 By their very nature, HTTP intermediaries are men-in-the-middle, and 3750 3765 represent an opportunity for man-in-the-middle attacks. Compromise of 3751 the systems on which the proxies run can result in serious security3752 and privacy problems. Proxies have access to security-related3766 the systems on which the intermediaries run can result in serious security 3767 and privacy problems. Intermediaries have access to security-related 3753 3768 information, personal information about individual users and 3754 3769 organizations, and proprietary information belonging to users and 3755 content providers. A compromised proxy, or a proxy implemented or 3756 configured without regard to security and privacy considerations, 3757 might be used in the commission of a wide range of potential attacks. 3758 </t> 3759 <t> 3760 Proxy operators need to protect the systems on which proxies run as 3761 they would protect any system that contains or transports sensitive 3762 information. In particular, log information gathered at proxies often 3763 contains highly sensitive personal information, and/or information 3764 about organizations. Log information needs to be carefully guarded, and 3765 appropriate guidelines for use need to be developed and followed. 3766 (<xref target="abuse.of.server.log.information"/>). 3767 </t> 3768 <t> 3769 Proxy implementors need to consider the privacy and security 3770 content providers. A compromised intermediary, or an intermediary 3771 implemented or configured without regard to security and privacy 3772 considerations, might be used in the commission of a wide range of 3773 potential attacks. 3774 </t> 3775 <t> 3776 Intermediaries that contain a shared cache are especially vulnerable 3777 to cache poisoning attacks. 3778 </t> 3779 <t> 3780 Implementors need to consider the privacy and security 3770 3781 implications of their design and coding decisions, and of the 3771 configuration options they provide to proxyoperators (especially the3782 configuration options they provide to operators (especially the 3772 3783 default configuration). 3773 3784 </t> 3774 3785 <t> 3775 Users of a proxy need to be aware that proxies are no more trustworthy than3786 Users need to be aware that intermediaries are no more trustworthy than 3776 3787 the people who run them; HTTP itself cannot solve this problem. 3777 3788 </t> … … 3807 3818 phrases, header field-names, and body chunks) &SHOULD; be limited by 3808 3819 implementations carefully, so as to not impede interoperability. 3809 </t>3810 </section>3811 3812 <section title="Denial of Service Attacks on Proxies" anchor="attack.DoS">3813 <t>3814 They exist. They are hard to defend against. Research continues.3815 Beware.3816 3820 </t> 3817 3821 </section>
Note: See TracChangeset
for help on using the changeset viewer.