Re: Trusted proxy UI strawman

On 16.06.2014 12:34, Stephen Farrell wrote:
> Hiya,
>
> On 16/06/14 04:01, bizzbyster@gmail.com wrote:
>> Hi Stephen,
>>
>> Our users want this so we are building it -- and we prefer to provide
>> them with a mechanism to opt in and out on a per site basis as well
>> as solve the problem of transitive trust introduced by standard MITM
>> proxies. While changes to the TLS layer are not required, it is the
>> most straightforward way to provide optimization for HTTPS web sites
>> for a service provider that has already deployed web acceleration via
>> proxies for HTTP-schemed web sites. Ideally the protocol changes we
>> make to our proxy and our web browser, including users on commercial
>> airlines like JetBlue and United, will be standardized so that our
>> users will get optimization when using other browsers and also when
>> they are using our browser when communicating with other proxies.
> I think the word "user" in the above is conflating people (with a
> browser), content authors and n/w operators, at least. I (as a
> user visiting web sites) do not "want this," nor do I as a content
> author, nor do I as a (very very tiny:-) web site admin. And I
> definitely do not "want this" for my calendar nor IMAP etc.
I as a father don't want my kids (as users) to see inappropriate 
content. I as a user often don't want web sites sending me tracking 
cookies, ads, viruses and many other things. I as a (very very tiny:-) 
web site admin (http://home.zinks.de/) can't guarantee that nobody will 
hack my site and misuse it. I as a user don't want my calendar be hosted 
by anybody in the Internet. Question is how this can be achieved? Maybe 
an intercepting HTTP proxy in the home router or a service of a mobile 
network operator can be part of the solution. Better solutions always 
welcome.

> So I don't agree that borking TLS is the most straightforward way
> to do something that I want, for at least 3 or 4 definitions of
> me as a user. And I'm pretty sure that I'm not at all alone in that.
> (But wasn't a lot of the above said already on this list?)
>
>> "If HTTP needs a proxy solution,please aim to develop an HTTP
>> solution and do not affect the many other protocols and applications
>> within and beyond the IETF that depend on TLS and that do not need an
>> MITM."
>>
>> What did you have in mind? I'm really interested in alternatives that
>> do not involve modifying the TLS layer.
> Mostly I have in mind not borking TLS;-)
+1
> I'm sorry to seem so negative here, but when there are such
> conflicting requirements, I guess that's gonna be the case.
> In my defence, I think I can fairly claim that "don't bork
> TLS" is actually a positive statement overall.
>
> Cheers,
> S.
Up to now TLS was independent from HTTP but this was broken with ALPN. 
An extension tied to HTTP through ALPN should not break any non HTTP use 
of TLS.

Roland

Received on Friday, 20 June 2014 10:29:49 UTC