Re: multiplexing -- don't do it

On 04/06/2012 06:30 PM, Roberto Peon wrote:
> 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.

So we've a web site, a browser-side (hopefully!) middlebox and a
browser playing a "who's the TLS endpoint" game. I don't think
that's easy to get right in a secure (enough) way but I look forward
to reading the I-D.

S

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

Received on Friday, 6 April 2012 17:43:51 UTC