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

( Kari Hurtta <hurtta-ietf@elmme-mailer.org> was bouncing after MX change.
  I reverted that change. )

Alex Rousskov <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> 
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 Wednesday, 1 March 2017 19:27:35 UTC