Re: multiplexing -- don't do it

On Fri, Apr 6, 2012 at 7:05 PM, Stephen Farrell
<stephen.farrell@cs.tcd.ie>wrote:

>
>
> 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:-)
>

Fair enough :) I won't go address them one by one, but I think a good way
to think about it is that the current situation is, in certain cases,
people deploy transparent SSL MITM proxies which are evil. For the
situations where an organization may want to deploy one of these, we'd
rather they use an explicit trusted https proxy instead.


> 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.


OK.


>
>
> 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.
>>>
>>>
>>>
>>