Re: [TLS] TLS Proxy Server Extension

[David McGrew <[e-mail]>]

Hi Martin,

On Jul 27, 2011, at 11:17 AM, Martin Rex wrote:

> Matt McCutchen wrote:
>>
>> On Tue, 2011-07-26 at 08:01 -0700, David McGrew wrote:
>>> I would like to request feedback on a new draft that Philip  
>>> Gladstone
>>> and I put together, which aims to solve some of the security  
>>> problems
>>> that happen when there is a (HTTP) proxy present and TLS is in use.
>>
>> It doesn't seem that this work is in any way specific to HTTP.
>
> Only for Web-Browser scenario can I personally see a very limited
> value that does not amount to 100% wiretapping.
>
> Are you aware of rfc2804 "IETF Policy on Wiretapping"?
>
>  http://tools.ietf.org/html/rfc2804
>
> Standardizing MITM attacks on TLS-protected communication
> ("lawful intercept?") seems like an extremely bad idea to me.

Standardizing MITM attacks would be awful, but that's not at all what  
the draft is proposing.

>
> Checking whether some data conforms to a certain company policy will
> almost always be illegal in European countries, where we have
> sensible data protection laws.

Firewalls are illegal in Europe?  That can't be right.

IANAL, but it appears that the approach of the draft (which notifies  
the client about the presence of a proxy, as well as provides info on  
the server) could help to meet the EU Data Protection Directive, in  
that it informs the data subject when his/her personal data are being  
processed by a proxy, a condition that must be met in some cases.

>>
>>
>> - One approach would be to do a real escrowed TLS where the client
>> negotiates directly with the server but releases the  
>> confidentiality key
>> and optionally also the integrity key to the proxy.  This subsumes  
>> all
>> of the above concerns but doesn't allow the proxy to manipulate the
>> handshake in any finer way than blocking the connection if it doesn't
>> like the outcome.
>
> For the purpose of "centralized malware screening", for the incoming
> Web traffic of Web Browsers that are well known to interpret such
> data in arbitrarily stupid ways (such as active content, img src,  
> (i)frame,
> javascript, css), sharing the encryption traffic keys with the Proxy
> would be perfectly sufficient, and that also enables the clients
> to clearly limit who is able to read the traffic.  No super-CA- 
> equivalent
> keys would need to be on the malware-scanning Proxy.
>
>


In what way is a protocol that propagates secret keys to a proxy any  
better with regard to privacy?   Note that if such a protocol is used  
by a server, then the client is not informed.

David