Re: [TLS] TLS Proxy Server Extension

[Martin Rex <[e-mail]>]

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.

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.


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


-Martin