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

   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.


   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

   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
   ( 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

   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

   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

   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

   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

   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

   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

8.  Security Considerations


9.  IANA Considerations


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
   1600 Amphitheatre Pkwy
   Mountain View, CA


Narayanan                Expires April 24, 2014                 [Page 9]