Changeset 2594


Ignore:
Timestamp:
28/01/14 01:23:03 (6 years ago)
Author:
fielding@…
Message:

(editorial) clarify why network intermediaries are indistinguishable at a protocol level from a MitM; see #531

Location:
draft-ietf-httpbis/latest
Files:
2 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.html

    r2593 r2594  
    920920               when Transport Layer Security (TLS, <a href="#RFC5246" id="rfc.xref.RFC5246.1"><cite title="The Transport Layer Security (TLS) Protocol Version 1.2">[RFC5246]</cite></a>) is used to establish confidential communication through a shared firewall proxy.
    921921            </p>
    922             <p id="rfc.section.2.3.p.9"><span id="rfc.iref.i.3"></span> <span id="rfc.iref.t.2"></span> <span id="rfc.iref.c.3"></span> The above categories for intermediary only consider those acting as participants in the HTTP communication. There are also
     922            <p id="rfc.section.2.3.p.9">The above categories for intermediary only consider those acting as participants in the HTTP communication. There are also
    923923               intermediaries that can act on lower layers of the network protocol stack, filtering or redirecting HTTP traffic without the
    924                knowledge or permission of message senders. Network intermediaries often introduce security flaws or interoperability problems
    925                by violating HTTP semantics. For example, an "<dfn>interception proxy</dfn>" <a href="#RFC3040" id="rfc.xref.RFC3040.1"><cite title="Internet Web Replication and Caching Taxonomy">[RFC3040]</cite></a> (also commonly known as a "<dfn>transparent proxy</dfn>" <a href="#RFC1919" id="rfc.xref.RFC1919.1"><cite title="Classical versus Transparent IP Proxies">[RFC1919]</cite></a> or "<dfn>captive portal</dfn>") differs from an HTTP proxy because it is not selected by the client. Instead, an interception proxy filters or redirects
     924               knowledge or permission of message senders. Network intermediaries are indistinguishable (at a protocol level) from a man-in-the-middle
     925               attack, often introducing security flaws or interoperability problems due to mistakenly violating HTTP semantics.
     926            </p>
     927            <p id="rfc.section.2.3.p.10"><span id="rfc.iref.i.3"></span> <span id="rfc.iref.t.2"></span> <span id="rfc.iref.c.3"></span> For example, an "<dfn>interception proxy</dfn>" <a href="#RFC3040" id="rfc.xref.RFC3040.1"><cite title="Internet Web Replication and Caching Taxonomy">[RFC3040]</cite></a> (also commonly known as a "<dfn>transparent proxy</dfn>" <a href="#RFC1919" id="rfc.xref.RFC1919.1"><cite title="Classical versus Transparent IP Proxies">[RFC1919]</cite></a> or "<dfn>captive portal</dfn>") differs from an HTTP proxy because it is not selected by the client. Instead, an interception proxy filters or redirects
    926928               outgoing TCP port 80 packets (and occasionally other common port traffic). Interception proxies are commonly found on public
    927929               network access points, as a means of enforcing account subscription prior to allowing use of non-local Internet services,
    928                and within corporate firewalls to enforce network usage policies. They are indistinguishable from a man-in-the-middle attack.
    929             </p>
    930             <p id="rfc.section.2.3.p.10">HTTP is defined as a stateless protocol, meaning that each request message can be understood in isolation. Many implementations
     930               and within corporate firewalls to enforce network usage policies.
     931            </p>
     932            <p id="rfc.section.2.3.p.11">HTTP is defined as a stateless protocol, meaning that each request message can be understood in isolation. Many implementations
    931933               depend on HTTP's stateless design in order to reuse proxied connections or dynamically load-balance requests across multiple
    932934               servers. Hence, a server <em class="bcp14">MUST NOT</em> assume that two requests on the same connection are from the same user agent unless the connection is secured and specific
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r2593 r2594  
    515515   establish confidential communication through a shared firewall proxy.
    516516</t>
    517 <t><iref primary="true" item="interception proxy"/>
    518 <iref primary="true" item="transparent proxy"/>
    519 <iref primary="true" item="captive portal"/>
     517<t>
    520518   The above categories for intermediary only consider those acting as
    521519   participants in the HTTP communication.  There are also intermediaries
    522520   that can act on lower layers of the network protocol stack, filtering or
    523521   redirecting HTTP traffic without the knowledge or permission of message
    524    senders. Network intermediaries often introduce security flaws or
    525    interoperability problems by violating HTTP semantics.  For example, an
     522   senders. Network intermediaries are indistinguishable (at a protocol level)
     523   from a man-in-the-middle attack, often introducing security flaws or
     524   interoperability problems due to mistakenly violating HTTP semantics.
     525</t>
     526<t><iref primary="true" item="interception proxy"/>
     527<iref primary="true" item="transparent proxy"/>
     528<iref primary="true" item="captive portal"/>
     529   For example, an
    526530   "<x:dfn>interception proxy</x:dfn>" <xref target="RFC3040"/> (also commonly
    527531   known as a "<x:dfn>transparent proxy</x:dfn>" <xref target="RFC1919"/> or
     
    534538   non-local Internet services, and within corporate firewalls to enforce
    535539   network usage policies.
    536    They are indistinguishable from a man-in-the-middle attack.
    537540</t>
    538541<t>
Note: See TracChangeset for help on using the changeset viewer.