Re: multiplexing -- don't do it

On 04/06/2012 05:54 PM, William Chan (陈智昌) wrote:
> On Fri, Apr 6, 2012 at 6:42 PM, Stephen Farrell
> <stephen.farrell@cs.tcd.ie>wrote:
>
>>
>>
>> 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 see more than two missing pieces. For example, why would a bank
or healthcare web site find this acceptable, what about TLS client-
authentication, or even channel-bindings, how's the user or browser
know where the right proxy is at *all* times, how'd this work at
home, in an open hotspot etc. etc. The paragraph above does not
answer any of these questions, and its too much for any sensibly
sized email to answer:-)

I think this really really needs a worked out spec. I'm not saying
that's needed today, but IMO it's needed before it'd be safe to
assume that this approach will work and would garner IETF consensus.

S

>
>
>>
>> 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 17:06:08 UTC