Re: [TLS] TLS Proxy Server Extension

[David McGrew <[e-mail]>]

On Aug 1, 2011, at 9:15 AM, Martin Rex wrote:

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

On the contrary, the goal here is to not have the proxy impersonate  
any other device, at least not impersonate in the cryptographic sense.

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

It's hard to parse that sentence, but if I understand you right, you  
think that it is important for the client to have a strong assurance  
that the subject of the server certificate is an active participant in  
the session.   I agree that is a highly desirable property.

I think the right theoretical approach to analyzing this sort of  
protocol would be to start with a formal model of TLS as a two-party  
authentication protocol, and extend it to accomodate a three-party  
system with the appropriate role definitions.  Fortunately, only the  
authentication aspects need to be considered, and some of the key  
establishment goals can be ignored, which makes the analysis easier.   
If we had the freedom to design the system from scratch, the obvious  
approach would be to have C, S, and P each issue nonces that get  
signed by each other party, along with the other data that gets  
currently signed, and indication of the role of each signer.  What is  
most interesting is: how close can one get to this ideal protocol by  
extending TLS?

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

On the above three points: allowing a proxy to coordinate betwen two  
TLS sessions allows one to preserve most of the TLS protocol and  
implementation.   In contrast, a solution that propagates session keys  
will require new implementation work for the data plane, state  
management, and so on.  If the proxy attempts to modify the session,  
all sorts of significant crypto problems will crop up.  There will be  
HTTP proxies that expect to modify the traffic, and it would be unwise  
to expect that a proxy implementer would respect the injunction to not  
modify the session, if a specification for session key propagation  
were developed.

It seems like a major difference that we have is that you expect a  
"read only" solution to be viable, while I don't.  A read-only  
decryption proxy would be considerably easier to implement correctly.   
However, I have zero confidence that a read-only decryption proxy  
would not evolve into a read/write proxy, which would introduce very  
significant security problems.

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

Your personal opinion on AEAD goes against a lot of theory and  
standards work of the last decade.  Have you considered providing your  
criticisms in writing?

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

Then think about the situation in which the proxy has the encryption  
keys and the authentication keys, and yet there is just a single TLS  
session, and consider the changes that would be needed to the TLS  
protocol in order to retain security even when the proxy is modifying  
the session data.


>  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

No, that's not right, at least not if "impersonate" is meant in the  
cryptographic sense.   If "impersonate" is meant in the sense that a  
proxy can modify the traffic passing through it, then yes, that is a  
goal for the system; it is a requirement if TLS is to be used to  
protect communications when an HTTP proxy is present (for many types  
of proxies).


> in any case
> and will always have all keying material available to do anything bad
> to either or both peers.
>

In any solution in which a proxy has session keys, it is required that  
the client and server trust the proxy to do the right thing.

One thing that really surprises me about your line of thinking is the  
fact that you feel that a protocol that can propagate a session key to  
a proxy would encourage better respect of privacy.  A server could use  
that protocol to pass keys to a middlebox without the knowledge or  
consent of the client, and the client could do so without the  
knowledge or consent of the server.   With the key propagation  
approach, there is very little that you and I can do to prevent this  
sort of behavior.  (Side note: one could design a solution that  
required both the client and server to approve of the presence of the  
proxy; in fact, I've been through that design exercise.  However, it  
would be easy for implementers to ignore the stipulation that both  
sides accede to the proxy, and they would be motivated to do so.)

I think we've both stated our views well enough that people have a  
reasonable idea of what we think.   It would be good to let others who  
care about the topic have a chance to offer their own thoughts.

David

> 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