- From: 陈智昌 <willchan@chromium.org>
- Date: Tue, 18 Feb 2014 23:37:38 -0800
- To: Thomas Fossati <TFossati@velocix.com>
- Cc: Patrick McManus <pmcmanus@mozilla.com>, Salvatore Loreto <salvatore.loreto@ericsson.com>, HTTP Working Group <ietf-http-wg@w3.org>, "draft-loreto-httpbis-trusted-proxy20@tools.ietf.org" <draft-loreto-httpbis-trusted-proxy20@tools.ietf.org>, GUS BOURG <gb3635@att.com>
On Tue, Feb 18, 2014 at 10:57 PM, Thomas Fossati <TFossati@velocix.com> wrote: > On 19/02/2014 02:02, "William Chan (陈智昌)" <willchan@chromium.org> wrote: >>And furthermore, I should add that I don't really think it's in the >>users' interests to have an intermediary be able to snoop listen in on >>all their https traffic. > > It’s not the https traffic that would be snooped, but the http traffic > carried over HTTP/2.0 + TLS If this is the case, I'm less concerned. I misinterpreted the "trusted" part of the proxy proposal as implying that the proxy would be trusted to snoop on https traffic, as that's how we've previously used the term. If this proxy has no more privilege than any other forward proxy, that sounds mostly fine to me. That said, I still agree with Patrick that there doesn't seem any reason to allow differentiation of http vs https traffic. If the user agent and origin agree to put http traffic over a user-agent<=>origin TLS connection, then they should be allowed to do so without having to mark it via ALPN. If the user agent really wanted to opt into letting the proxy server see the http request, it can issue the http request to the proxy and let the proxy fetch it from the origin, just like we do for all other HTTP forward proxies today. I recommend rephrasing this as a secure proxy proposal, rather than a trusted proxy proposal. Securing the user-agent<=>proxy connection sounds like a fine endeavor to me (indeed, Chromium already supports this behavior), and I'd like to see it standardized. > >>I don't really see the value for end users in >>standardizing any mechanism for doing this. > > E.g. getting lower latencies on mobile networks (due to improved caching > at the edge). >
Received on Wednesday, 19 February 2014 07:38:10 UTC