RE: ext#9: OppSec and Proxies

Yes, the Google DCP and Opera cases are explicitly configured on the client side whereas OppSec is server-controlled, but a key area they overlap is that both are logically tunneling HTTP URIs over TLS. IOW, the end user is navigating to http://example in both cases, and the encryption of the communication is, by its nature, optional in both cases.

So in the case of HTTP requests, it is often advantageous (and possibly mandatory) for both the end user and the server to allow an intermediary to directly participate in the delivery (see) the content. For example, an intermediary managed by a network operator (e.g. IT, cellular, satellite) can dramatically improve end user performance and/or reduce content delivery costs. 

The problem is that there isn't a simple, scalable way to support this at the moment. All of the various proxy proposals circulated within HTTPbis require either the end user to opt in (explicit proxy) or the origin server to essentially "opt in" (alt svcs). Neither party can know how to configure the most appropriate intermediary where the network is constantly changing, such as with mobile.

An optimal scenario would allow the "nearest" intermediary to participate in the HTTP2 delivery stream, and it seems there are approaches where the HTTP2 protocol can facilitate this. For example, maybe the Via header could be suitable for such an approach, such as the following strawman: "Via: h2 RANgateway, 1.1 FwdProxy" could notify the user agent that "RANgateway" could be an intermediary for tunneling HTTP2 via TLS. It would be up to the user agent to pick whether/which intermediary it wants to connect to. This could applicable for the reliable tunneling of HTTP2, and perhaps the OppSec case. 

If other folks have other suggestions, let's surface them now in the event that a protocol tweak would be desirable.

--Will

-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com] 
Sent: Tuesday, July 29, 2014 9:24 AM
To: emile.stephan@orange.com
Cc: Mark Nottingham (mnot@mnot.net); HTTP Working Group (ietf-http-wg@w3.org)
Subject: Re: ext#9: OppSec and Proxies

On 29 July 2014 08:46,  <emile.stephan@orange.com> wrote:
> Currently a mobile client can already OppSec connect to performance 
> proxies (Google DCP and Opera cases were discussing in meeting) hosted 
> on the Internet, but one at a time.

This isn't really opportunistic; these proxies are typically configured based on a name or a certificate fingerprint.  That's a different proposition that what we're talking about here.

That said, I think that we need to examine the trade-offs when we talk about securing proxy communications.  With HTTP/2 to the proxy, we can use ALTSVC frames (though not Alt-Svc header fields) to enable opportunistic security if we are very careful.  But it might be easier on balance to simply say that the proxy is configured to use an TLS connection that is authenticated against a specific name.  e.g., rather than saying the proxy is at http://proxy.orange.com, say that it is at https://proxy.orange.com

Received on Friday, 1 August 2014 00:47:29 UTC