Re: Attack against handshake protocol

[daw@xxxxxxxxxxxxxxx (David Wagner)]

Yes, you are correct.  But such an attack would need to recover the
master_secret (or break both MD5 and SHA HMAC, which is unlikely);
which means that the attacker would need to get the client to accept
a ciphersuite which uses a weak public-key encryption component.

Therefore, if RSA were broken tomorrow, every TLS implementation that
supports RSA would be insecure (even if those implementations also
supported some secure public-key algorithm, such as Diffie-Hellman, say).

So a TLS implementation is only as strong as the weakest of the public-key 
algorithms it supports.

This is yet another reason that TLS applications which need strong
crypto should disable the export ciphersuites.

(Making an exportable, anonymous, or auth-only ciphersuite mandatory
to support would be a disaster; apps needing high-grade security
need to be able to turn off support for all of those ciphersuites.)



In article <s3d76a87.036@xxxxxxxxxx>,
Tammy Carter  <ietf-tls@xxxxxxxxxxxxx> wrote:
> 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.  And, if
> they are made mandatory as per Jeff S's last email,
> this could open up vulnerabilities for software that is just trying
> to comply with the standard.