Network Working Group V. Narayanan Internet-Draft Google Intended status: Informational October 21, 2013 Expires: April 24, 2014 Explicit Proxying in HTTP - Problem Statement And Goals draft-vidya-httpbis-explicit-proxy-ps-00 This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Abstract This document describes the issues with HTTP proxies for TLS protected traffic and motivates the need for explicit proxying capability in HTTP. It also presents the goals that such a solution would need to satisfy and some example solution directions. Status of This Memo This Internet-Draft is submitted to IETF 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 April 24, 2014. Copyright Notice Narayanan Expires April 24, 2014 [Page 1] Internet-Draft Explicit Proxying Problem Statement October 2013 Copyright (c) 2013 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Proxying Needs Today . . . . . . . . . . . . . . . . . . . . 3 4. Proxy Configurations Today . . . . . . . . . . . . . . . . . 4 5. Problems With Proxies Today . . . . . . . . . . . . . . . . . 5 6. Explicit HTTP Proxying . . . . . . . . . . . . . . . . . . . 5 6.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 6 6.1.1. On Users, Intermediaries And Content Providers . . . 6 6.1.2. On Today's Practices . . . . . . . . . . . . . . . . 6 6.2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Potential Solution Directions . . . . . . . . . . . . . . . . 8 7.1. Do Nothing . . . . . . . . . . . . . . . . . . . . . . . 8 7.2. Signed Policy Per Origin . . . . . . . . . . . . . . . . 8 7.3. Explicit Proxy Detection using HTTP/TLS . . . . . . . . . 8 7.4. Object Level Security in HTTP . . . . . . . . . . . . . . 9 7.5. TLS Origin Cert Exchanges . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 11. Normative References . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction Web proxies that are present in the communication path between clients and servers are fairly common practice. There are many reasons one may employ a proxy, but the commonly deployed scenarios today are at odds with client to server privacy. While in almost all cases, some kind of user consent is received to carry traffic through proxies, such consent is fairly vague and the user is often unaware about the extent to which proxies have visibility into their communications. In some cases, such visibility may be construed as an unacceptable violation of privacy. This document describes the types of proxies and the issues with the currently used models. It makes a case for legitimizing the use of Narayanan Expires April 24, 2014 [Page 2] Internet-Draft Explicit Proxying Problem Statement October 2013 proxies while providing sufficient transparency to the endpoints. Towards that end, it also sets goals towards designing such an explicit proxying mechanism for http communication. Note that the scope of this document is limited to HTTPS only - HTTP communication not protected by TLS is out of scope for this discussion. 2. Motivation The move to securing http connections is often to provide a confidential channel for exchange of information between a client and server. In the presence of a proxy, a secure channel may perceived to be end-to-end when it is in fact not the case. To fix this, proxies must be visible to the communicating endpoints. However, without an interoperable solution, explicit proxying of connections becomes an issue. The motivations to make proxying explicit include: o Making secure communications possible for users o Allowing endpoints to choose not to communicate in the presence of an intermediary o Ensuring that a proxy is authorized to be in the path o Allowing detection of modified content o Allowing the ability to cache content in intermediate entities 3. Proxying Needs Today There are number of reasons proxies have been deployed in networks. Some of these reasons include: o Policy Enforcement Authentication and bandwidth policies may be often enforced using a proxy. This allows the model of having conditional connectivity or limits on connectivity such as may be observed in a hotel or an airport hotspot, among other places. For TLS protected connections, this type of policy enforcement becomes difficult (the connections just fail until the user finds a way to authenticate with the proxy). But, it may be useful to support this using explicit proxying techniques for a better experience. o Caching Very widely used on the Internet, caching proxies allow serving of content from topologically closer sources in order to preserve network resources and improve user experience. Narayanan Expires April 24, 2014 [Page 3] Internet-Draft Explicit Proxying Problem Statement October 2013 o Content Modification Certain networks employ content modifying proxies that generally modify content to improve network and overall user experience. For instance, proxies in mobile networks may need to modify content to change the codec for sake of older devices. However, sometimes, content modification proxies have also been known to make high definition content unavailable - while arguably this may be in the best interest in balancing the overall health of the network (a bad network isn't good for any user), this is also highly debatable. o Content Filtering Content filtering proxies may prevent malware, but may also prevent access to sites that are in violation of the administrative policies. This filtering may be by size, type or subject matter. o Content Inspection Some proxies may be installed with a need to inspect and flag inappropriate content (e.g., in schools). As can be seen, some of the proxies need access to the content, while others do not. 4. Proxy Configurations Today Proxies used to be configured manually by having the users specify the proxy information in the browser settings. However, due to the difficulty in effectively implementing this approach (specifically that the user needed to be involved when he/she moved out of the proxy's network), two proxying models have evolved. One is the group configuration policies that are used in enterprises, where a device that is part of an enterprise gets subjected to the enterprise proxying policies by pre configuration. Another is the model of "interception" or "transparent" proxies became widely popular and is also in a fairly large use today. In the "transparent" proxy model, neither endpoint knows about the interception. Transparent proxies can be employed in the presence of TLS (HTTPS) as well, when certificate pinning is disabled. Most deployments end up disabling certificate pinning so that proxying can be accomplished. The client machines are often configured with root certs that will allow it to accept the proxy generated ephemeral certificate for the server. Future configurations of proxies continues to be a problem and explicit mechanisms of configuring Narayanan Expires April 24, 2014 [Page 4] Internet-Draft Explicit Proxying Problem Statement October 2013 proxies may be necessary to motivate the move away from interception proxies. There are also tunneling proxies, where HTTP CONNECT may be used to tunnel the client requests to the server. 5. Problems With Proxies Today The use of proxies leads to a number of privacy issues. To summarize: o The user often has no knowledge that their data exchanges are passing through an interception proxy that potentially has visibility to the actual content exchanged. o The server has no knowledge of the presence of the proxy and hence, cannot refuse to serve sensitive content over a proxied connection. o The weakened security model, when certificate pinning is disabled at a general level, allows inspection of content potentially by entities other than legitimate proxies that the user may be willing to give access to. This is especially true in enterprises with a multitude of platforms, devices and browsers, where explicit configuration of proxy certificates is an administrative burden. o The client can no longer authenticate the real server. Hence, the client has no influence on certificate revocation checks and any visible warnings to the user are made infeasible. o Client authentication (and hence mutual authentication) is made infeasible. Any server relying upon mutual authentication to establish a TLS connection cannot work with transparent proxies. o The user has no way of detecting whether content has been modified en route. o The client is susceptible to downgrade attacks, as it cannot do any policy enforcement on versions or algorithms. With privacy becoming more and more important, it is important for us to support solutions that allow awareness of a privacy breach to both users and the servers, when that happens. To this effect, it is important that proxies be explicitly supported and detected. 6. Explicit HTTP Proxying Narayanan Expires April 24, 2014 [Page 5] Internet-Draft Explicit Proxying Problem Statement October 2013 The problems illustrated in this document call for explicit knowledge of on-path proxies to the user and the content provider. The key assumptions and goals driving this target are stated below. 6.1. Assumptions 6.1.1. On Users, Intermediaries And Content Providers o Users configure proxies and forget about the configuration. o Users have limited control over provider installed certificates. * Often, the user's only choice is to not sign up for service at all. o Users may not wish to have some or any of their communications intercepted, even when they are on a network for which they previously configured a proxy. o Intermediaries have various legitimate reasons for wanting to inspect traffic: * Cache content * Implement network traffic policies (e.g. legal compliance, malware detection, etc) o Content providers may not wish to serve certain content in anything less than an end-to-end secure fashion. 6.1.2. On Today's Practices o Many networks seem to leave the traffic on port 443 untouched and unblocked today, likely as a result of both the importance of the data and the relative rarity of communications using TLS. It is unclear how this might change as TLS protected traffic increases, if we continued to not have a solution for explicit proxying. o 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. o Many, if not most, mobile devices using cellular networks use proxies and several of them act as transforming proxies. Narayanan Expires April 24, 2014 [Page 6] Internet-Draft Explicit Proxying Problem Statement October 2013 o 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. 6.2. Goals These are the goals of a solution aimed at making proxying explicit in HTTP. o In the presence of a proxy, users' communications SHOULD at least use a channel that is point-to-point encrypted. o Users MUST be able to opt-out of communicating sensitive information over a channel which is not end-to-end private. o Content-providers MAY serve certain content only in an end-to-end confidential fashion. o Interception proxies MUST be precluded from intercepting secure communications between the user and the content-provider. o User-agents and servers MUST know when a transforming proxy is interposed in the communications channel. o User-agents MUST be able to detect when content requested with an https scheme has been modified by any intermediate entity. o Entities other than the server or user-agent SHOULD still be able to provide caching services. o User agents MUST be able to verify that the content is in fact served by the content provider. o 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. o Ideally, HTTP URI semantics SHOULD NOT change, but if it does, it must remain backwards-compatible. o Configuration and deployment of proxies should be as easy as currently used solutions. o Introduction of explicit proxying MUST NOT require a flag day upgrade - in other words, it should work with existing client and content provider implementations during the transition. Narayanan Expires April 24, 2014 [Page 7] Internet-Draft Explicit Proxying Problem Statement October 2013 7. Potential Solution Directions There are several potential directions this work can take, some of which are clearly undesirable and some that are more viable. This section is not intended for an exhaustive description of each solution - rather, it is aimed at serving as a starting point for discussions. Note that more than one of these directions may need to be adopted and brought together for a complete solution - so, each section here is not intended to be standalone and complete. 7.1. Do Nothing This is a scenario that continues to support interception proxies in current modes. The fundamental premise of this document is based on the fact that this is bad. 7.2. Signed Policy Per Origin RFC6454 specifies a method by which there can be a signed policy per origin. However, such coarse granularity of providing a policy for an entire domain is often not useful and hence, this is rarely used in practice. 7.3. Explicit Proxy Detection using HTTP/TLS Means of: o Explicit signaling of presence of proxy from user agent to server. o Signaling to indicate user preference for end-to-end secure communication o Signaling to indicate content unavailability via proxies o Verification of proxy identity to detect untrusted proxies o Serving interstitial pages to manage portals that enforce bandwidth, connectivity times, etc. The above can be accomplished in a variety of ways, including HTTP/ TLS error codes, HTTP2.0 proxy signaling semantics and HTTP/TLS exchange of proxy identities. Narayanan Expires April 24, 2014 [Page 8] Internet-Draft Explicit Proxying Problem Statement October 2013 7.4. Object Level Security in HTTP The ability to detect modified content is needed. Specifically: o Object level integrity protection of content by content provider o Object level encryption by content provider (optionally) 7.5. TLS Origin Cert Exchanges The ability to exchange the true certificate chain of the server in TLS exchanges so that clients can make better decisions about servers. 8. Security Considerations TBD 9. IANA Considerations TBD 10. Acknowledgments List of names here - TBD 11. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Author's Address Vidya Narayanan Google 1600 Amphitheatre Pkwy Mountain View, CA USA Email: vn@google.com Narayanan Expires April 24, 2014 [Page 9]