One document matched: draft-rpeon-httpbis-exproxy-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY RFC2616 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml'>
<!ENTITY RFC2854 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2854.xml'>
<!ENTITY RFC5246 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml'>
<!ENTITY RFC6454 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6454.xml'>
<!ENTITY RFC3986 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml'>
<!ENTITY RFC6249 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6249.xml'>
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc strict="no" ?>
<rfc category="info" ipr="trust200902" docName="draft-rpeon-httpbis-exproxy-00">
<front>
<title abbrev="exproxy">Explicit Proxies for HTTP/2.0</title>
<author initials="R." surname="Peon" fullname="Roberto Peon">
<organization>Google, Inc</organization>
<address>
<email>fenix@google.com</email>
</address>
</author>
<date day="8" month="June" year="2012" />
<area>Applications</area>
<keyword>HTTP</keyword>
<abstract>
<t>This document describes a method for connecting to a proxy via a secure channel, allowing, disallowing, and detecting any transforms that the proxy may perform, and allowing the proxy to connect via secure channel to another site on the user's behalf.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Overview">
<t>It has been proposed that a secure channel be utilized for all HTTP/2.0 traffic coming from users using browsers. As a first order effect, this would obviously improve security, but it could have the second order effect of banishing all communication over any secure channel for lack of a mechanism to allow the owners of the network to apply desired policies to the messaging going on within it. Another second order effect could be user selection away from this protocol if it doesn't meet their performance expectations. This document proposes mechanisms intended to ameleoriate these issues. This document does not exhaustively cover configuring a proxy in a browser.</t>
</section>
<section title="Definitions">
<t>
<list style="hanging" hangIndent="6">
<t>user-agent: The program or device which a human interacts with directly and which typically initiates the transport layer connection or session</t>
<t>client: Synonym for user-agent</t>
<t>user: The human using the user-agent</t>
<t>server: The computer or device which typically accepts a connection and serves data</t>
<t>content-provider: The server to which the user-agent ultimately wishes to speak</t>
<t>configured-proxy: The entity to which the user-agent is explicitly configured to speak and which the user-agent expects will connect to the content-provider on the user-agent's behalf</t>
<t>trusted-proxy: A configured-proxy to which the user-agent has been configured to give decryption key material</t>
<t>caching-proxy: A configured-proxy to which the user-agent has NOT been conigured to give decryption key material</t>
<t>end-to-end: From the user-agent to the content-provider</t>
<t>point-to-point: Between any two pairs of adjacent entities. If the entities are user-agent and content-provider, this is also end-to-end, but for any other pair of entities, it is only point-to-point.</t>
<t>secure-hash: A cryptographic hash resistent to preimage and collision attacks, whether as part of a hash tree (e.g. Merkle tree), hash list, etc. </t>
</list>
</t>
</section>
<section title="What it looks like today">
<t> Today:
<list style="hanging" hangIndent="6">
<t> Using <xref target="RFC5246">TLS</xref> over port 443 is often the exception rather than the rule. </t>
<t> Many users use radio-based devices which transmit data effectively in the clear, allowing their credentials and identity to be stolen. </t>
<t> Many networks seem to leave the traffic on port 443 untouched and unblocked, likely as a result of both the importance of the data and the relative rarity of communications using TLS. </t>
<t> Entities which need to inspect traffic on port 443 today are forced to either block port 443 or to deploy an intercepting proxy and install root certs on all devices which may use the network. In the latter case, the deployed proxy impersonates both the content-provider to the user-agent, and the user-agent to the content-provider. Though there is work to allow users to <xref target="DANE"> detect these situations</xref>, support is not widespread.</t>
<t> Users are likely to see both beneficial and detrimental behavior as a result of transparent proxies.</t>
<t> Many, if not most, mobile devices using cellular networks use proxies</t>
<t> Users and sites have only one mechanism for specifying point-to-point security policy for <xref target="RFC2616">HTTP</xref>, which is the scheme of the URI identifying any particular resource.</t>
</list>
</t>
</section>
<section title="Where we would like to be">
<t> In the future:
<list style="hanging" hangIndent="6">
<t> A user's communications should use a channel which is point-to-point secure by default for all communications. </t>
<t> Users should be able to opt-out of communicating sensitive information over a channel which is not end-to-end private. </t>
<t> Only proxies which are known to and configured by the user should be allowed to intercept communications between the user and the content-provider. </t>
<t> User-agents and servers should know when a proxy is interposed in the communications channel.</t>
<t> User-agents should be able to detect when content requested with an https scheme has been modified by a proxy. </t>
<t> Caching should still be a service which can be provided by entities other than the server or user-agent.</t>
<t> Caches, when allowed, should be exceedingly difficult to poison.</t>
<t> A set of signaling semantics should exist which allows the content-provider and the user to have the appropriate level of security or privacy signaled per resource.</t>
</list>
</t>
</section>
<section title="Problems with end-to-end privacy?">
<t> Entities may wish to have a proxy interposed in communication for a number of reasons including (but not limited to):
<list>
<t> Looking for and blocking malware</t>
<t> Filtering for content by size, type, or subject matter</t>
<t> Provide caching services so as to improve the user experience</t>
</list>
</t>
<t> Unfortunately, if communication is to be done in majority or completely using end-to-end privacy, then none of the above use-cases are possible without installing root certs on users' devices. There are several possible consequences for having only end-to-end privacy:
<list style="hanging" hangIndent="6">
<t> It may become common for entites to install root certs on users' devices, and users may become accustomed to doing this, even on their personaly owned devices. This could cause a breach of all trust-chains, and could reduce aggregate security.</t>
<t> Entities which own networks may decide to block port 443, else face noncompliance of policy or law. This would obviously reduce aggregate security.</t>
<t> Clients at the end of long, thin pipes may decide that speed matters more than security, and disable use of the new, secure protocol. This would also obviously decrease aggregate security.</t>
</list>
</t>
<t> The assumptions and potential consequences in this section should be carefully deliberated.</t>
</section>
<section title="Proposed Solution: Use Explicit Proxies">
<t>Since failing to allow for some kind of interception technique may reduce aggregate security, it is suggested we design for and allow explicit proxies which may examine contents as they pass by. This is not something to be done lightly, and so we must be careful to allow the user-agent to select an appropriate level of trust. We must also provide for a fallback in cases where the proxy or server does not adhere to this proposal so that in the worst case we get what we have today. </t>
<t> For the purpose of this document, it is assumed that the user locates a piece of paper upon a wall and reads it, typing these proxy settings into a configuration field for their user-agent. This is obviously not the only possible configuration mechanism, but it may, sadly, be the most secure. It is assumed that alternate distribution techniques may be discussed.</t>
<t> For HTTPS schemes, if a proxy is configured:
<list style="hanging" hangIndent="6">
<t> The user-agent MUST indicate to the content-provider that it is going through a proxy via the tunnel as the first bit of information presented.</t>
<t> If a link in an <xref target="RFC2854">HTML</xref> document includes a secure-hash of the data, e.g. <a href="https://foo.bar.com/baz" hash=0ACC827F19F36BA>, and the link was provided in a secure manner (e.g. over an end-to-end communications channel that includes integrity checks), then the user-agent MAY request the indicated resource directly from the explicitly configured proxy. The configured proxy MAY serve the data from its cache, but it MUST NOT modify the content in any way. The user-agent MUST reject any received data if is unable to verify its integrity or if the secure-hash does not match the hash over the provided data. The presence of the secure-hash is, itself, signals that the content may be fetched in a non-private channel. <xref target="RFC6249">RFC6249</xref> provides some descriptions of cryptographic-hash implementations.</t>
<t> The above need not be the only mechanism for providing signals that data can be served via a cache, but the data MUST always be verifiably unmodified. As an example, other mechanisms for providing secure-hashes could be:
<list style="hanging" hangIndent="6">
<t>The <xref target="RFC3986">URI syntax</xref> could be modified to include a hash of the contents.</t>
<t>A signed manifest may be sent which includes one or more secure-hashes of byte-ranges of the data, either fetched via a separate resource or sent in-band. The signature, would, of course, have to be validated before the secure-hashes were to be trusted, and before any requests were sent in a non end-to-end private channel. <xref target="RFC6249">RFC6249</xref> provides some descriptions of such mechanisms. <xref target="BITTORRENT">Bittorrent provides another example</xref>.</t>
<t>Within the TLS Tunnel, frames may be sent describing the secure-hash of a byte-range of the data, by request from the user-agent. Multiple secure-hashes may be returned if the byte-range mapping on the server differs from that requested by the client. This alternative is most interesting for its ability to describe dynamically generated data (such as live video) safely and in a way that can be consumed by the client in a closer-to-real-time manner, and for supporting range-requests. If implemented in a protocol similar to <xref target="SPDY">SPDY</xref>, this could be accomplished with HEADER frames or equivalent.</t>
</list>
</t>
<t> If the user agent has no means of verifying the data is unmodified, the user-agent either MUST tunnel through the proxy by doing a CONNECT with a TLS tunnel, or the user-agent MUST reuse a previously-created tunnel offering the same security. If the proxy refuses this communication the user-agent MUST attempt a connection directly to the content-provider, avoiding the proxy.</t>
</list>
</t>
<t> We're proposing that user-agents allow for two levels of security for any proxy:
<list>
<t> Trusted Proxy - all data sent and received is inspected by the proxy</t>
<t> Caching Proxy - only data which could be served from the cache is inspected by the proxy</t>
</list>
It is also possible for a user-agent to use a proxy in both configured and trusted-proxy modes. This document does not include mechanisms for signaling this.
</t>
<t> In the case where the proxy connects to the content-provider using a secure, multiplexed connection, the following diagram and description would apply:</t>
<figure>
<artwork><![CDATA[
Anne = the client or user-agent
Bob = point-to-point secure multiplexed connection from Anne<->Chris
Chris = the proxy
Don = point-to-point secure multiplexed connection from Chris<->Ed
Ed = the content-provider
Client Proxy Content-provider
| | |
| /==spdy-connection=Bob==\ | /==spdy-connection=Don==\ |
Anne --connect-stream-- Chris --connect-stream-- Ed
\=======================/ \=======================/
]]>
</artwork>
</figure>
<t> In the case where the user-agent has been configured with Chris as a trusted-proxy, either Anne's connect-stream MUST use either a null-cipher, or Anne
MUST provide the decryption key material to Chris immediately after tunnel establishment, and before any data traverses the tunnel.<vspace />
In the case where the user-agent has been configured with Chris as a caching proxy, Anne's connect-stream SHOULD NOT use the null cipher, and Anne SHOULD NOT provide the decryption key material to Chris.</t>
<t> In *all* cases, the user-agent must indicate that it is traversing a proxy within the connect-tunnel, and indicate whether the proxy is a trusted-proxy or caching-proxy.</t>
<t> In the case where the proxy cannot use a secure, multiplexed connection when connecting to the content-provider, the following diagram and description would apply. It is hoped that this case will never be selected as a spec-compliant implementation for forward proxies as it offers significantly less scalability than the option proposed above.</t>
<figure>
<artwork><![CDATA[
Anne = the client or user-agent
Bob = point-to-point secure multiplexed connection from Anne<->Chris
Chris = the proxy
Ed = the content-provider
Client Proxy Content-provider
| | |
| /==spdy-connection=Bob==\ | |
Anne --connect-stream-- Chris <--connect-stream--> Ed
\=======================/
]]>
</artwork>
</figure>
<t> In both trusted-proxy and caching-proxy cases, Anne must select a non-null cipher for use in the tunnel. In both the trusted-proxy and caching-proxy cases, the proxy simply forwards the tunnel's bytes to Ed and vice-versa.
In the case where the user-agent has been configured with Chris as a trusted-proxy, Anne MUST provide the decryption key material to Chris immediately after tunnel establishment, and before any data is sent along the tunnel.<vspace />
In the case where the user-agent has been configured with Chris as a caching-proxy, Anne SHOULD NOT provide the decryption key material to Chris. If Anne selected a null-cipher in this case, Chris MUST reject the connection, forcing Anne to attempt to fallback on a separate connection.</t>
<t> In *all* cases, the user-agent must indicate that it is traversing a proxy within the connect-tunnel, and indicate whether the proxy is a trusted-proxy or caching-proxy.</t>
</section>
<section title="Mixed trust mode">
<t> If a signaling mechanism is created which reliably indicates that some data be used in caching-proxy mode, where other data be retrieved in trusted-proxy mode, the user-agent MAY create two tunnels (one for each mode). A mechanism to signal this is not included in this document. A single tunnel MUST NOT be used, as it is impossible to both allow inspection and privacy simultaneously using mechanisms as proposed here.</t>
</section>
<section title="Rejected Alternatives">
<t>
<list style="hanging" hangIndent="6">
<t>Do nothing - <vspace />
This assumes that port 443 won't be blocked, which is contrary to the assumptions in this document. </t>
<t>100% trust of the proxy at all times - <vspace />
Hopefully it is obvious why this is bad. </t>
<t>Signed policy per response -<vspace />
With this mechanism, the user-agent would expect a piece of signed metadata with each message from the content-provider. This has the disadvantage of being fairly chatty, but the worst part is the requirement to be shuttling around private-key material on the part of the content-provider. This material should be held closely; anything requiring its constant use will likely undermine its secrecy. It is also expensive to be signing things all the time...</t>
<t>Signed policy per domain or <xref target="RFC6454">origin</xref> -<vspace />
With this mechanism, the user-agent would expect a piece of signed metadata with the first response to a request. The one-domain-one-policy seems too restrictive for today's site compositions, and doesn't match HTTP's current caching semantics.</t>
</list>
</t>
</section>
<section title="Impact on other areas of the protocol">
<t> If we assume that we'll see widespread 'Caching Proxy' deployment, and we assume that the proxies will multiplex multiple incoming streams over fewer outgoing connections, then we may lose some of the current benefits of header compression, and must worry about endpoint per-connection stream limits.</t>
<t> If the mechanisms in this document are widely used, mechanisms which reduce the number of RTTs for the TLS handshake phase(s) including anything which allows for fast, efficient, safe resumption would be of high importance.</t>
</section>
<section title="Security Considerations">
<t> Everything in this document should be carefully scrutinized as everything in this document impacts security.</t>
<t> A particular worry is the 'Trusted Proxy' mode. Does its presence undermine end-to-end security so much that the benefit of the proposal is moot? In particular, would users as a whole or in a significant part of the population be inclined to ignore (hopefully dire) warnings about using 'Trusted Proxy' mode when they didn't own the proxy?</t>
</section>
<section title="Requirements Notation">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref target="RFC2119"/>.
</t>
</section>
<section title="Acknowledgements">
<t>
<xref target="RFC6454"/>;
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC2616;
&RFC2854;
&RFC3986;
&RFC5246;
&RFC6249;
&RFC6454;
<reference anchor="DANE" target="http://tools.ietf.org/html/draft-ietf-dane-protocol.txt">
<front>
<title>DANE</title>
<author initials="P" surname="Hoffman" fullname="Paul Hoffman">
<organization>VPN Consortium</organization>
</author>
<author initials="J" surname="Schlyter" fullname="Jakob Schlyter">
<organization>Kirei AB</organization>
</author>
<date month="April" year="2012"/>
</front>
</reference>
<reference anchor="BITTORRENT" target="http://www.bittorrent.org/beps/bep_0003.html">
<front>
<title>The BitTorrent Protocol Specification</title>
<author initials="B" surname="Cohen" fullname="Bram Cohen">
</author>
<date month="February" day="28" year="2008"/>
</front>
<seriesInfo name="BITTORRENT" value="11031"/>
</reference>
<reference anchor="SPDY" target="http://tools.ietf.org/html/draft-mbelshe-httpbis-spdy">
<front>
<title>SPDY PROTOCOL</title>
<author initials="M" surname="Belshe" fullname="Mike Belshe">
<organization>Twist</organization>
</author>
<author initials="R" surname="Peon" fullname="Roberto Peon">
<organization>Google</organization>
</author>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:38:10 |