Re: Comments on Explicit/Trusted Proxy

Yoav Nir <ynir@checkpoint.com> wrote:

> Here's one (I'm a co-author)
> 
> http://tools.ietf.org/html/draft-mcgrew-tls-proxy-server
> 
> One reason this was rejected is that MitM proxies are used for corporate firewalls and national firewalls, so the use case seems to be "Alice wants to post to Twitter trashing president Assad. Mallory who works for the secret police would like to catch her, so he installs a proxy."  The feedback said that if whoever wants the inspection (call them Mallory for now) can configure trust on Alice's client, they might as well install spyware instead. Another idea that was floated was to have the client send the keys to the trusted proxy. That way, the client could send just the encryption key (but not the hash key) so the proxy would be able to decrypt, but not forge. I didn't like that, but I did try to write a draft describing it:
>  
> http://tools.ietf.org/html/draft-nir-tls-keyshare
> 
> I still think this solution is unwieldy.
> 
> Anyway, the TLS WG can re-consider things. NPN was suggested several times. If there is a use case that is not "Mallory wants to see what Alice is telling Bob", a request from this WG would go a long way, regardless of which mechanism is preferred for enabling a trusted proxy.

Another use case is Alice operating both the client(s) and
the trusted proxy.

In this use case the trusted proxy should be able to MITM some,
but not all, requests and the client(s) should be able to verify
and signal this to Alice.

Mallory should not be able to silently MITM anything and
Alice obviously doesn't want to install spyware instead of
configuring a trust relationship, even though she could.

Having a standard for this would be useful for proxies like Privoxy.

Fabian