Re: explicitly authenticated proxy: new draft

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

Received on Thursday, 12 June 2014 19:50:20 UTC