Re: forward HTTPS proxy | Re: The future of forward proxy servers in an http/2 over TLS world

On 03/01/2017 03:35 PM, Mike Bishop wrote:

> More fundamentally broken is that you have to /believe/ the proxy when
> it claims the server certificate to be something.

In this model, the user has instructed the browser to believe the proxy.
There are other models, of course, but I do not see anything
_fundamentally broken_ with this approach. While it may feel
uncomfortable for a browser to obey the user decision, it is not
fundamental breakage IMHO.

This is similar to saying that saving an HTTPS web page to a PDF file is
fundamentally broken because the browser has to believe the PDF reader
not to screw up with validated content. Can that PDF reader change
content or otherwise mislead the user? Absolutely! Is that possibility a
good enough excuse to block "Save As PDF" export? No.

Another example are CDNs. Their model is as "fundamentally broken" as
the secure proxy model, but browsers do not seem to be fighting them.
Why is a browser happy with the certificate provided by a CDN? In both
cases, we are dealing with a single-party consent: The user does not
authorize CDN usage and the origin server does not authorize proxy
usage. Why is it acceptable for a bleeding CDN but not for a forward
proxy to risk betraying our trust in the infrastructure as a whole?


> The server doesn't
> have access to the certificate, and so can't sign any nonce the client
> might request.

In this model, the user did not ask the browser to validate the origin
response against the origin certificate. In this model, the user trusts
the proxy to do that. The browser may display (and can even validate!)
the origin certificate.

As you said, other, more complex models may give browsers more control
at the expense of adding their own "strongly negative properties".

Alex.


> -----Original Message-----
> From: hurtta@hurtta09lk.keh.iki.fi [mailto:hurtta@hurtta09lk.keh.iki.fi]
> On Behalf Of Kari Hurtta
> Sent: Wednesday, March 1, 2017 11:27 AM
> To: Alex Rousskov <rousskov@measurement-factory.com>; Willy Tarreau
> <w@1wt.eu>
> Cc: Kari Hurtta <hurtta-ietf@elmme-mailer.org>; HTTP working group
> mailing list <ietf-http-wg@w3.org>
> Subject: forward HTTPS proxy | Re: The future of forward proxy servers
> in an http/2 over TLS world
> 
>  
> 
> ( Kari Hurtta <hurtta-ietf@elmme-mailer.org
> <mailto:hurtta-ietf@elmme-mailer.org>> was bouncing after MX change.
> 
>   I reverted that change. )
> 
>  
> 
> Alex Rousskov <rousskov@measurement-factory.com
> <mailto:rousskov@measurement-factory.com>>
> 
> https://lists.w3.org/Archives/Public/ietf-http-wg/2017JanMar/0377.html
> 
>  
> 
>> To be more precise, the _browser_ needs that, but, yes, this is
> 
>> probably required, and that is exactly why I mentioned secure response
> 
>> signing (or something like that) as a prerequisite. The proxy would
> 
>> need to somehow forward origin's response signature or public
> 
>> certificate (at least). This is where an HTTP extension is required.
> 
>> Everything else is already supported (at the protocol level) AFAICT.
> 
>  
> 
> If HTTP/2 can be assumed for that https connection from browser to
> proxy, the that extension can be new HTTP/2 frame. I think that this
> fits to that place.
> 
>  
> 
> Proxy sends that frame to browser before responses HEADERS frame.
> 
>  
> 
> This allows browser only show status after the fact. Browser can not
> examine origin's certificate before it sends to proxy
> 
>  
> 
> HEADERS
> 
>      + END_STREAM
> 
>      + END_HEADERS
> 
>        :method = GET
> 
>        :scheme = https
> 
>        :path = /
> 
>        :authority = example.com
> 
>  
> 
>  
> 
> Willy Tarreau <w@1wt.eu <mailto:w@1wt.eu>>
> 
> https://lists.w3.org/Archives/Public/ietf-http-wg/2017JanMar/0375.html
> 
>  
> 
>> That's why I think that a technical solution like trusted proxies can
> 
>> be good. Let the user know whether he can have a TLS tunnel to the
> 
>> origin or has to retry in clear using "GET https://". Let's have the
> 
>> same warnings as when I'm asked whether or not I want to share my
> location with the site.
> 
>  
> 
> That can be new HTTP response code for CONNECT.
> 
>  
> 
>  
> 
> I think these are new protocol components which are needed on that solution.
> 
>  
> 
>  
> 
> / Kari Hurtta
> 
>  
>

Received on Thursday, 2 March 2017 00:25:46 UTC