Re: Attack against handshake protocol

[EKR <ekr@xxxxxxxxxx>]

Tammy Carter <TCARTER@xxxxxxxxxx> writes:

> In section F.1.3, Detecting Attacks Against the Handshake Protocol, 
> the draft says that an attacker may influence the handshake exchange 
> to influence the suite which is chosen.  It then states that the attacker
> must change multiple handshake messages, which will cause the
> client and server to generate different values for the handshake hashes
> and cause the attack to be discovered.
> 
> It seems to me that, if a weak enough cipher suite were agreed upon
> by the client and the server, the attacker would also be able
> to compute the master secret quickly enough to play 
> "man in the middle."  In this way, the attacker could, effectively,
> get one packet from the server, change it as desired, and pass
> it along to the client.  Likewise, the attacker could receive client
> packets, change them as desired, and pass them along to the 
> server.  At least until the attacker gained the desired access
> or information.
>
> My question is how "weak" would the cipher suite have to be
> to permit this to happen?
>
> My concern is that the exportable cipher suites are either 
> already in this category or will soon fall into it.
I don't believe that this attack is a problem in practice.

Remember that the finished message is:
     struct {
         opaque md5_hash[16];
         opaque sha_hash[20];
     } Finished;

     md5_hash       MD5(master_secret + pad2 +
                        MD5(handshake_messages + Sender +
                            master_secret + pad1));
     sha_hash        SHA(master_secret + pad2 +
                         SHA(handshake_messages + Sender +
                             master_secret + pad1));

     handshake_messages    All of the data from all handshake messages
                           up to but not including this message.  This
                           is only data visible at the handshake layer
                           and does not include record layer headers.

So, you need to recover the master secret in order to forge
a 'finished' message. (Unless we assume that this construct is
totally broken in which case we've got bigger problems on
our hands). But if you know the master secret, you
don't need to interfere with the handshake because you can derive
all the keying material and mount any attack you like.

Note that there is a less subtle argument that requiring short
key asymmetric cryptography is a security hole, but I don't
believe that anyone has proposed restrictions in what asymmetric
key lengths must be supported, and (of course) nothing in
being MANDATORY forbids application developers from giving
users the option to restrict themselves to long keys...
	
-Ekr

-- 
[Eric Rescorla                             Terisa Systems, Inc.]
		"Put it in the top slot."