W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: explicitly authenticated proxy: new draft

From: lingli deng <denglingli@gmail.com>
Date: Tue, 17 Jun 2014 13:39:26 +0800
Message-ID: <CAHWmbsM9d4fcOVeSa3xJ51jw3cgstX74afb+BZSsCawrBmHg8w@mail.gmail.com>
To: Salvatore Loreto <salvatore.loreto@ericsson.com>
Cc: Martin Nilsson <nilsson@opera.com>, "<ietf-http-wg@w3.org>" <ietf-http-wg@w3.org>
Hi Sal and Martin,

I am also interested in working on proxy certificate idea.


2014-06-13 3:49 GMT+08:00 Salvatore Loreto <salvatore.loreto@ericsson.com>:

> as Martin N. stated below Opera and Ericsson have spent some time to
> implement the auth-proxy draft
> but at same time, as it is always the case, learned quite while
> implementing, putting together the different
> part and testing them all together
> (the prototype is a modified browser running on Android and a proxy
> running on Linux)
> I would summarise the main parts of the proposal in the following three:
> - the pro-active attitude of the client to send http:// traffic over TLS
> - the possibility for an end user to become aware of a proxy presence and
> the freedom
> for the user to provide or not consent to it to "proxy" the http://
> traffic over TLS and eventually
> to revoke the consent. As you can imagine this part is mainly about how to
> modify the UI to do that.
> - the ability of a proxy to identify itself thru a Proxy certificate
> Martin N. is right when he says that at moment there is no other HTTP2
> clients that pro-actively
> sends any http traffic over TLS… and at moment it applies to Opera Turbo
> but we have start from somewhere, isn't it?
> I also agree that it is a scenario that is largely used in different
> products for HTTP/1.1
> and would be also worth to discuss from that angle,
> so in the next version I will try to generalise it for both HTTP/1.1 and
> HTTP/2
> About the Proxy Certificate, for sure it needs more work to get it right
> from all the aspects.
> However I have talked with several people that seem to like the idea
> and maybe are willing to put some cycles on it or on some aspect of it.
> Unfortunately I haven't seen anyone yet sending those comments and
> suggestions publicly on
> the mailing list… so if you have please do that.
> Yes I do think is a good idea to move the Proxy Certificate idea in a
> separate as it is
> a concept that if well defined can be defined in several scenarios.
> I am for sure willing to continue to work on it together with Martin and
> anyone else is interested
> to work on it.
> br
> Salvatore
> On Jun 12, 2014, at 5:31 PM, Martin Nilsson <nilsson@opera.com> wrote:
> > On Mon, 05 May 2014 08:49:34 +0200, Salvatore Loreto <
> salvatore.loreto@ericsson.com> wrote:
> >
> >>
> >> we have produced a new draft that proposes the definition of an
> Explicitly Authenticated
> >> Proxy as intermediary of normally unprotected "http://" URI scheme
> requests and responses of HTTP2 traffic.
> >>
> >
> > We've spent some time at Opera implementing this to try see how it holds
> > together. Given that it assumes that the client pro-actively sends http
> > traffic over TLS it doesn't appear to apply cleanly on normal browsing,
> > but it is applicable to Opera Turbo, where all http traffic is tunneled
> > through our proxies. I fear it might be a bit too narrow use case as is
> to
> > standardize. Some suggestions
> >
> > - Given how the negotiation mechanism works this is locked to HTTP/2.
> > There are still a lot of HTTP/1 use cases around for something like this.
> >
> > - There are many places where root certificates are added to silently
> > force proxies into TLS streams. I think those should be considered here
> as
> > well (e.g. intercepting all TLS, but instead give the user the choice to
> > abort the request). If we can move to a place where no one has a
> > legitimate reason to modify the client root store, that would be an
> > overall win.
> >
> > - The client certificates needs work. Some of these fields are
> > underspecified, like logo and presentation name. The certificates also
> > need to be locked to a network, with that network information (APN,
> > MCC/MNC etc) signed in the certificate. When the proxyFunctions are
> > defined we should make them verifiable, and decide if they should
> describe
> > effects (faster, smaller), functions (compression, caching) and/or
> > privileges (modify content, inspect headers).
> >
> > I think the proxy certificates is a nice idea that might even work
> outside
> > of TLS connections to verify that you are using the expected proxy. I'll
> > take a stab at defining it a bit more, possibly in a separate draft.
> >
> > /Martin Nilsson
> >
> > --
> > Using Opera's revolutionary email client: http://www.opera.com/mail/
> >

邓灵莉/Lingli Deng
中国移动通信研究院/China Mobile Research Institute
e-mail: denglingli@chinamobile.com
tel: 15801696688-3367
mobile: 13810597148
Received on Tuesday, 17 June 2014 05:39:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC