Re: multiplexing -- don't do it

The proposal is: the resources served via SSL and which were requested with
the https scheme would return a signed description of the data being
returned as well as policy info from the site about mitm/trusted proxies.
The policy could be to allow certain content, to tunnel via connect through
it for other content, or to deny access.
The client would be the entity executing the signed policy.
If that policy isn't present and there is no explicit mitm, then the client
would do as it does for https today. If the policy is missing and there is
an mitm, the client must display an error to the user and refuse to proceed.

Anything which proposes auto configuration of a proxy would need some more
deep thought... but this problem is no different for hospitals, etc. than
it is today.
This is important. This problem exists today. The way I've seen it working
is that the captive portals refuse arbitrary access to any site but the
author site  through :443 until you've authenticated.

-=R
On Apr 6, 2012 10:07 AM, "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:-)
>
> 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.
>>>
>>>
>>>
>>
>