Re: Proxies (includes call for adopting new work item, call for input)

I agree that those two aspects 1) trusting a single vendor and 2) functional incompleteness on the client make Split UA proxies different from traditional web proxies like squid.

But if a split UA proxy were to decrypt my TLS traffic on the server side, I'd want to know about it and be able to say no. You could argue that the certificate installation step is no longer meaningful -- http://caffeinatetheweb.com/presentations/trusted_proxy.html#/3. But the notification and user control piece is exactly the same as non split UA proxies -- http://caffeinatetheweb.com/presentations/trusted_proxy.html#/4.

Peter


On Jun 23, 2014, at 1:13 PM, Martin Thomson <martin.thomson@gmail.com> wrote:

> On 23 June 2014 00:48, Diego R. Lopez <diego@tid.es> wrote:
>> My point is that you need to trust those people at different moments (one
>> for installation, another one when using it) and that makes that you always
>> have to trust two different set of people. Unless I am missing something and
>> you assume that a split browser scenario implies full control of both parts
>> by the user.
> 
> 
> That's not right.  You don't need to trust your network provider at
> all.  That's a core tenet of Internet security: "you give your packets
> to the attacker to deliver."
> 
> You might trust them to deliver some packets.  But to say that is the
> same as trusting them with the details of a banking session would be a
> gross oversimplification of the concept of trust.
> 
> p.s., When I said split UA, there are two things: one is the line that
> ekr has been following, which is that you are trusting a single
> vendor, which is the most important from a security analysis
> perspective.  The other is pure functionality: your browser is not
> complete without the network side component.  In some of these cases,
> the code that sits on the device is potentially unable to function
> without the server piece.
>