DUnderstanding the Pitfalls of SSLv2 - Implementing SSL/TLS Using Cryptography and PKI - page 626

The payload, after removing the MAC and the padding, is

47 45 54 20 2f 69 6e 64 65 78 2e 68 74 6d 6c

GET / i ndex . ht ml

20 48 54 54 50 2f 31 2e 31 0d 0a

H T T P / 1 . 1 \r \n

which is exactly what would have been sent if there had been no SSL involved.
The response from the server is similar. The remaining four packets are the
standard TCP FIN/ACK FIN/ACK shutdown sequence. There is no SSL involved
here.

Problems with SSLv2

So, what's wrong with SSLv2? Everything is in place — encryption, MAC veri-
fi cation, certifi cate verifi cation. Why was SSLv2 deprecated?

Man-in-the-Middle Attacks

Man-in-the-middle attacks, which public-key cryptography and certifi cate
authorizes are supposed to thwart, are discussed in Chapter 5. However, one
signifi cant weakness of SSLv2 is that the fi rst few packets — the ClientHello
and the ServerHello — aren't themselves protected against man-in-the-middle
attacks. An attacker can insert himself in between the client and the server,
and downgrade the connection by, for example, removing all encryption options
except for DES, or even making it look as though the client can only support
export-grade (that is, easily crackable) ciphers. The client never notices. Unless
the client is specifi cally confi gured to never negotiate weak ciphers, the con-
nection continues as requested.

Truncation Attacks

SSLv2 uses the standard TCP shutdown mechanism (the FIN packet) to indicate
that the connection is closed. An attacker can easily forge this packet, however,
leading to the same sort of truncation problems that led to the use of MACs in
the fi rst place.

Same Key Used for Encryption and Authentication

SSLv2 doesn't allow the peers to negotiate a separate encryption key versus a
MAC key. This simplifi es a brute-force attack because the attacker has additional
data with which to attack the key.