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

Re: multiplexing -- don't do it

From: 陈智昌 <willchan@chromium.org>
Date: Fri, 6 Apr 2012 18:54:27 +0200
Message-ID: <CAA4WUYg6PBgXq9JxDmi73nXtDqmAe=rsitgxufwXBnDwRinYBQ@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: Nicolas Mailhot <nicolas.mailhot@laposte.net>, Mike Belshe <mike@belshe.com>, ietf-http-wg@w3.org
On Fri, Apr 6, 2012 at 6:42 PM, Stephen Farrell

> On 04/06/2012 05:07 PM, William Chan (陈智昌) wrote:
>> Haven't we been down this read already on this mailing list? Let's create
>> and use explicit trusted https proxies (if you don't know what I'm talking
>> about here, make sure you've read some of these megathreads from the past
>> week).
> I've read those and I don't know what precisely is meant.

The browser connects to an explicitly configured HTTPS proxy (much like how
browsers can configure HTTP proxies today). Rather than using a CONNECT
tunnel, browsers issue a GET https://www.example.com, and the proxy does
the https transaction (SSL handshake, certificate validation, yada yada) on
the browser's behalf. That's why it's called "trusted", since you're
trusting this proxy to do that security sensitive stuff for you. There are
two missing pieces here. (1) need a way to provide integrity guarantees
(MACs or what not) on https content coming from the trusted proxy and (2)
need a way for browsers to figure out when to do https end-to-end or to
issue a GET https:// to a proxy (basically, do we want confidentiality or
not for this URL).

> I have doubts such a thing can be safely done in a way that'd
> result in IETF consensus.

I dunno, I thought that lots of the intermediary guys here seemed pretty
positive about it. I think everyone agrees transparent SSL MITM is lame.

> But, we won't know until someone writes the I-D describing
> this.
> S.
Received on Friday, 6 April 2012 16:54:56 UTC

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