Internet DRAFT - draft-rpeon-httpbis-exproxy
draft-rpeon-httpbis-exproxy
Network Working Group R. Peon
Internet-Draft Google, Inc
Intended status: Informational June 8, 2012
Expires: December 10, 2012
Explicit Proxies for HTTP/2.0
draft-rpeon-httpbis-exproxy-00
Abstract
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.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 10, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Peon Expires December 10, 2012 [Page 1]
Internet-Draft exproxy June 2012
Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. What it looks like today . . . . . . . . . . . . . . . . . . . 4
4. Where we would like to be . . . . . . . . . . . . . . . . . . 4
5. Problems with end-to-end privacy? . . . . . . . . . . . . . . 5
6. Proposed Solution: Use Explicit Proxies . . . . . . . . . . . 6
7. Mixed trust mode . . . . . . . . . . . . . . . . . . . . . . . 9
8. Rejected Alternatives . . . . . . . . . . . . . . . . . . . . 9
9. Impact on other areas of the protocol . . . . . . . . . . . . 10
10. Security Considerations . . . . . . . . . . . . . . . . . . . 10
11. Requirements Notation . . . . . . . . . . . . . . . . . . . . 11
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
13. Normative References . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Peon Expires December 10, 2012 [Page 2]
Internet-Draft exproxy June 2012
1. Overview
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.
2. Definitions
user-agent: The program or device which a human interacts with
directly and which typically initiates the transport layer
connection or session
client: Synonym for user-agent
user: The human using the user-agent
server: The computer or device which typically accepts a
connection and serves data
content-provider: The server to which the user-agent ultimately
wishes to speak
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
trusted-proxy: A configured-proxy to which the user-agent has
been configured to give decryption key material
caching-proxy: A configured-proxy to which the user-agent has
NOT been conigured to give decryption key material
end-to-end: From the user-agent to the content-provider
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.
Peon Expires December 10, 2012 [Page 3]
Internet-Draft exproxy June 2012
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.
3. What it looks like today
Today:
Using TLS [RFC5246] over port 443 is often the exception rather
than the rule.
Many users use radio-based devices which transmit data
effectively in the clear, allowing their credentials and
identity to be stolen.
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.
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 detect these situations [DANE], support is not widespread.
Users are likely to see both beneficial and detrimental
behavior as a result of transparent proxies.
Many, if not most, mobile devices using cellular networks use
proxies
Users and sites have only one mechanism for specifying point-
to-point security policy for HTTP [RFC2616], which is the
scheme of the URI identifying any particular resource.
4. Where we would like to be
In the future:
A user's communications should use a channel which is point-to-
point secure by default for all communications.
Peon Expires December 10, 2012 [Page 4]
Internet-Draft exproxy June 2012
Users should be able to opt-out of communicating sensitive
information over a channel which is not end-to-end private.
Only proxies which are known to and configured by the user
should be allowed to intercept communications between the user
and the content-provider.
User-agents and servers should know when a proxy is interposed
in the communications channel.
User-agents should be able to detect when content requested
with an https scheme has been modified by a proxy.
Caching should still be a service which can be provided by
entities other than the server or user-agent.
Caches, when allowed, should be exceedingly difficult to
poison.
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.
5. Problems with end-to-end privacy?
Entities may wish to have a proxy interposed in communication for a
number of reasons including (but not limited to):
Looking for and blocking malware
Filtering for content by size, type, or subject matter
Provide caching services so as to improve the user experience
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:
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.
Peon Expires December 10, 2012 [Page 5]
Internet-Draft exproxy June 2012
Entities which own networks may decide to block port 443, else
face noncompliance of policy or law. This would obviously
reduce aggregate security.
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.
The assumptions and potential consequences in this section should be
carefully deliberated.
6. Proposed Solution: Use Explicit Proxies
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.
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.
For HTTPS schemes, if a proxy is configured:
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.
If a link in an HTML [RFC2854] 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,
Peon Expires December 10, 2012 [Page 6]
Internet-Draft exproxy June 2012
signals that the content may be fetched in a non-private
channel. RFC6249 [RFC6249] provides some descriptions of
cryptographic-hash implementations.
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:
The URI syntax [RFC3986] could be modified to include a
hash of the contents.
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. RFC6249
[RFC6249] provides some descriptions of such mechanisms.
Bittorrent provides another example [BITTORRENT].
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 SPDY [SPDY], this
could be accomplished with HEADER frames or equivalent.
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.
We're proposing that user-agents allow for two levels of security for
any proxy:
Trusted Proxy - all data sent and received is inspected by the
proxy
Peon Expires December 10, 2012 [Page 7]
Internet-Draft exproxy June 2012
Caching Proxy - only data which could be served from the cache is
inspected by the proxy
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.
In the case where the proxy connects to the content-provider using a
secure, multiplexed connection, the following diagram and description
would apply:
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
\=======================/ \=======================/
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.
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.
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.
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.
Peon Expires December 10, 2012 [Page 8]
Internet-Draft exproxy June 2012
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
\=======================/
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.
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.
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.
7. Mixed trust mode
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.
8. Rejected Alternatives
Peon Expires December 10, 2012 [Page 9]
Internet-Draft exproxy June 2012
Do nothing -
This assumes that port 443 won't be blocked, which is contrary
to the assumptions in this document.
100% trust of the proxy at all times -
Hopefully it is obvious why this is bad.
Signed policy per response -
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...
Signed policy per domain or origin [RFC6454] -
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.
9. Impact on other areas of the protocol
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.
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.
10. Security Considerations
Everything in this document should be carefully scrutinized as
everything in this document impacts security.
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
Peon Expires December 10, 2012 [Page 10]
Internet-Draft exproxy June 2012
dire) warnings about using 'Trusted Proxy' mode when they didn't own
the proxy?
11. Requirements Notation
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 [RFC2119].
12. Acknowledgements
[RFC6454];
13. Normative References
[BITTORRENT]
Cohen, B., "The BitTorrent Protocol Specification",
BITTORRENT 11031, February 2008,
<http://www.bittorrent.org/beps/bep_0003.html>.
[DANE] Hoffman, P. and J. Schlyter, "DANE", April 2012,
<http://tools.ietf.org/html/draft-ietf-dane-protocol.txt>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2854] Connolly, D. and L. Masinter, "The 'text/html' Media
Type", RFC 2854, June 2000.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC6249] Bryan, A., McNab, N., Tsujikawa, T., Poeml, P., and H.
Nordstrom, "Metalink/HTTP: Mirrors and Hashes", RFC 6249,
June 2011.
[RFC6454] Barth, A., "The Web Origin Concept", RFC 6454,
Peon Expires December 10, 2012 [Page 11]
Internet-Draft exproxy June 2012
December 2011.
[SPDY] Belshe, M. and R. Peon, "SPDY PROTOCOL",
<http://tools.ietf.org/html/draft-mbelshe-httpbis-spdy>.
Author's Address
Roberto Peon
Google, Inc
Email: fenix@google.com
Peon Expires December 10, 2012 [Page 12]
