Subject: ext#9: OppSec and Proxies

From: Mark Nottingham <[email-masked]>
Date: Tue, 29 Jul 2014 16:38:21 +1000

<https://github.com/httpwg/http-extensions/issues/9>

We discussed this issue in Toronto, and the sense of the room there was to close this issue with no action, since there are a lot of different scenarios for how a client uses a proxy, as well as different kinds of proxies which might cause clients to do different things.

Any more discussion?

Regards,

--
Mark Nottingham   https://www.mnot.net/

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 29 Jul 2014 23:30:41 +1200

> We discussed this issue in Toronto, and the sense of the room there was to close this issue with no action, since there are a lot of different scenarios for how a client uses a proxy, as well as di…

If I am understanding the term "OppSec" correctly (does it still match
the millitary meaning?) then the administrators OPSEC policy itself
should be detailing these things, not HTTP spec.

All HTTP spec has to do is provide flexibility in access (CONNECT,
Upgrade, ALPN, Alt-Svc - good) and security operations (TLS, nothing,
home-grown message signatures - reasonable) which the policy selects
from. The onus is largely on implementations to retain interoperability
when such a policy prohibits or mandates certain traffic usage (within
HTTP spec).

For example Chrome by rejecting CONNECT+Upgrade and plain-text HTTP/2
has effectively omitted itself from several OpSec policy groups which
require open and/or recorded traffic within a network. The jail and
school controlled-network scenarios being the most well-known of these.

Amos

---

From: Roland Zink <[email-masked]>
Date: Tue, 29 Jul 2014 17:22:50 +0200

As a special case of OppSec mentioning that the connection from the 
client to the proxy can be https. Chrome support this with a pac file 
extension. But allowing the proxy to upgrade the client -> proxy 
connection to https would be nice too.

Regards,
Roland

---

From: <[email-masked]>
Date: Tue, 29 Jul 2014 15:46:55 +0000

Hi Mark,

Thank for giving me the opportunity to continue the discussion.

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.  These proxies implement functions like caching, compression or translation to improve customer experiences. Most of them encrypt the HTTP traffic but in different manners.

In all the cases these proxies don’t work well with services already deployed locally by the network operator the handset is connected too. The mitigation, if any, is performed with very poor mechanisms which do not allow the usage of an OppSec connection with the proxy of the network operator.

So there is gap here that we may describe in the proxy-problems draft and that we may start addressing in the http2-encryption draft.

Cheers

Emile

-----Original Message-----
From: Mark Nottingham [mailto:[email-masked]]
Sent: mardi 29 juillet 2014 08:38
To: HTTP Working Group
Subject: ext#9: OppSec and Proxies

Any more discussion?

Regards,

--

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 29 Jul 2014 09:23:48 -0700

On 29 July 2014 08:46,  <[email-masked]> 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

---

From: William Chow <[email-masked]>
Date: Fri, 1 Aug 2014 00:46:56 +0000

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:[email-masked]] 
Sent: Tuesday, July 29, 2014 9:24 AM
To: [email-masked]
Cc: Mark Nottingham ([email-masked]); HTTP Working Group ([email-masked])
Subject: Re: ext#9: OppSec and Proxies

On 29 July 2014 08:46,  <[email-masked]> 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