Re: [TLS] Protecting against a MITM

[Michael D'Errico <[e-mail]>]

>> RI with patched client / unpatched server:
>>
>>    People continue to suggest that with the RI extension, a client doesn't
>>    need to send it on its initial handshake.  This is completely wrong.
> 
> It is not "completely wrong". For a patched client, not sending a signal
> on the initial handshake (regardless of the form of that signal) matters
> if-and-only-if the client is going to refuse to interoperate with
> unpatched servers.

"Interoperating with unpatched servers" means exposing yourself to an attack.
We can't protect against that behavior.  It may initially be necessary to
do this until widespread adoption of the fix happens, but it is certainly
not safe long term.

Any fix that we come up with, if it is not used it will not protect you.
That is obvious.

> If a client would continue with an initial connection to a server that it
> knows is unpatched, then the attack is unavoidable in that case. That is
> true for *any* possible solution, not just RI.

Agreed.

The difference is that if you *DO* want to avoid handshaking with unpatched
servers then with RI it requires you to a) use TLS, not SSL, because you need
to b) send and receive an extension; you also c) base your decisions on in-
the-clear hello messages that are subject to tampering, and d) don't send a
Finished message if the server *appears* not to support RI, thus you can't
prove or disprove an attack was underway.

With my proposal, you simply switch to a new Finished message calculation;
no changes to the bits on the wire, thus perfectly interoperable up until
the Finished message fails because the server is not upgraded.  And that is
what you want to happen if you are not being "lenient."  Further, if an
attack is happening and the server *is* upgraded, it can prove it since
neither of the two Finished calculations will match.  A MITM can not do
anything to cause one of them to match since it doesn't know the master
secret.

>>    A MITM attack will absolutely succeed if the server is not patched and
>>    the client does nothing different than it always has in the past.  Thus
>>    if RI is not used by the client in its first handshake, it gets zero
>>    protection even though it is aware of the MITM attack.  And even if the
>>    client does use the extension, it must rely on a possibly forged Server
>>    Hello to decide whether to continue with the handshake.
>>
>>    So the client has to send the extension on every handshake including
>>    the initial handshake.  This brings up all of the interoperability
>>    problems: lack of support for extensions even in TLS, no possible way
>>    to use extensions with SSLv3, mischief by a MITM (removing the
>>    extension from the hello messages, simulating a server "crash" when
>>    the extension is sent, etc.)
> 
> These kinds of "mischief by a MITM" won't work. The Finished hashes will
> fail to verify, and the attacker gains no advantage:

In most cases I think you are right, but imagine there is a server out there
that requires renegotiation to obtain client credentials.  In order to
continue providing service to clients, it may be configured to still perform
insecure renegotiations during a transition period.  A MITM can easily make
this server appear to break upon receiving the RI extension.

If the client has a fallback to not use the RI extension, then the MITM is
able to cause the client and server, both of which are patched, to revert
back to insecure behavior.

With my proposal, it is also possible for a MITM to alter the handshake, but
the difference is that the server can prove it happened since neither Finished
computation will match.  Because it notices an active attack, it can mount a
more effective defense, such as locking out that client's IP address (range)
from renegotiating and instead ask for client auth in the initial handshake.

>> This solution is to make available a modified Finished calculation that a
>> patched client can use for all handshakes including the initial one.  This
>> solution does not even break compatibility with old clients -- a server
>> would support BOTH the old and the new Finished message computation and do
>> the right thing based on which one was used by the client.
> 
> This has a significant disadvantage relative to the RI proposal:
> Consider a patched client that wants to connect to unpatched servers.
> With your suggested approach, such a client must use the old Finished
> message computation on an initial handshake (or else it must add a fallback
> in order to connect to those servers, which is undesirable). Therefore, it
> isn't distinguishable from an unpatched client by looking at cleartext
> handshake messages.

I'm suggesting to give up cleartext patch status for better attack detection
and better interoperability since there is NO change to bits on the wire, no
need for extensions or even TLS (SSLv3 can be fixed in exactly the same way).

A server can actually log when neither Finished message calculation matches
and alert the proper people to investigate the attack.  With RI this is not
possible since the client can't send its Finished message without risking an
attack.

> My proposal of changing the Finished hash computation for renegotiations
> only, plus sending an empty extension to signal patched status, does not
> have this disadvantage. It also does not rely on the extension for
> anything other than detection of patched/unpatched status.

This has the same problems as RI w.r.t. not being compatible with SSLv3 and
requiring extensions.  But it would work for peers that both support TLS with
extensions.

>> The only interoperability "problem" is when a patched client uses the new
>> Finished calculation when talking to an unpatched server[*] -- the
>> handshake will fail.  This is precisely what SHOULD happen -- the client
>> is protected from a potential MITM attack!
> 
> It is quite unrealistic to suppose that *all* client implementors will
> want to refuse to interoperate with unpatched servers. That has to be
> an option, not a requirement or assumption.

The whole premise of my message was based on providing a solution for a
patched client trying to protect against an unpatched server.  Any solution
we come up with MUST protect a patched client talking to a patched server, so
the only issue worth discussing is how to protect patched clients from an
unpatched server.  Or if a proposed solution fails the MUST, such as with the
fallback possibility when an RI client can be tricked into reconnecting
insecurely and a server accepting it.

If a client wants to throw caution to the wind and connect using the old
Finished message, that is its choice.  Nobody can force a client to be secure
if it doesn't want to be.  That does not mean that we shouldn't provide a
completely secure method to avoid and detect these attacks.

Mike