Re: [TLS] TLS Proxy Server Extension

[Martin Rex <[e-mail]>]

David McGrew wrote:
> 
> Again, it seems that you do not quite understand what we are trying to  
> achieve.   There is current practice that uses proxies in a way that  
> is bad for clients (and you outline many of the reasons below).  We  
> aim to improve the situation for clients and the security of the  
> overall solution.  One important point: it is possible to design a  
> solution in which the proxy does not contain a CA.

You're trying to give the proxy the authority to impersonate
_every_ server.  Whether it is through an super-CA-cert or whether
you're extending the protocol so that the client believes a forwarded
certificate with _no_ proof-of-posession for that cert is a mere
implementation detail, and has no impact of the size of the security
problem that you want to newly create.


> 
> Propagating TLS session key material is a worse idea for a lot of  
> reasons.  It would be a fragile solution in which easy-to-make  
> implementation mistakes could undermine security.

I'm sorry, but that is a completely bogus claim.

If the proxy is terminating both TLS connections, it will have access
to traffic encryption and mac keys of both connections can can leak
those just as easily.  Sharing the traffic encryption keys will not
make this any worse.


>
> It would require considerable new implementation work.

You mean because it would require an additional network channel to
talk to the proxy? yes.  It can not happen "by accident".


>
> It would make crypto validation considerably harder if not impossible.

Nope.  That is orthogonal.


>
> If it aimed to preserve end-to-end authentication, it would be
> fundamentally incompatible with Authenticated Encryption in general
> and the AEAD facility in TSL 1.2 in particular, and it would probably
> end up getting misused and abused in practice.

Correct, the use of AEAD would break the security, since this mode does
not use seperate traffic encryption and mac keys.  Personally, I consider
AEAD a bad idea, so I don't mind disabling these cipher suites when
traversing such a proxy.


>
> If it did not aim to preserve end-to-end authentication,  
> then it would require considerable changes to the TLS protocol, to  
> prevent keystream insertion attacks and keystream re-use.  Perhaps  
> worst of all, it would create a mechanism that could more easily be  
> abused; a server could (mis)use it and give away session keys without  
> the knowledge or consent of the client.

I have no clue what you mean.  If the proxy terminates the clients
TLS connection and establishes a new connection to the real server,
then it will have to impersonate the real server to the client in any case
and will always have all keying material available to do anything bad
to either or both peers.

So security-wise, the TLS proxy that you are proposing is at the
far end of badness, there is _nothing_ that can possibly be worse,
but a few thinghs might be *MUCH* better.


-Martin