RFC 6176 lists four reasons why SSL 2.0 must not be used, in its section 2:

• Message authentication uses MD5 [MD5]. Most security-aware users have already moved away from any use of MD5 [RFC6151].

• Handshake messages are not protected. This permits a man-in-the- middle to trick the client into picking a weaker cipher suite than it would normally choose.

• Message integrity and message encryption use the same key, which is a problem if the client and server negotiate a weak encryption algorithm.

• Sessions can be easily terminated. A man-in-the-middle can easily insert a TCP FIN to close the session, and the peer is unable to determine whether or not it was a legitimate end of the session.

However not all reasons are equivalent in gravity. The main security issue with SSL 2.0 is that it has no notion of verified closure: the SSL 2.0 connection ends when the underlying TCP connection is closed. An active attacker can force that, and neither client nor server can know whether the closure is really what the peer wanted. This is a problem when the protocol within the SSL tunnel uses the closure in a semantic way; e.g., with HTTP when there is no Content-Length header or chunked encoding (a rarity nowadays).

The three other reasons are less imperious, and can be debated:

• Though MD5 is thoroughly broken with regards to collisions, it still is quite strong when used in other ways, e.g. to build a MAC (as long as you do it properly). You should not use MD5 in new designs, but that does not mean that MD5, as it is used in SSL 2.0, can trivially be broken (or even non-trivially).
• Through the lack of protection of the handshake messages, attackers can force client and server to use a weaker cipher suite than what they could have used -- but one could say that the real issue here is that the client and server agree to use a weak cipher suite at all.
• Indeed, when the negotiated encryption is weak (a 40-bit "export cipher"), the MAC key is equally weak. But, there again, if the client and server agree to use weak crypto, they only get what they deserve.

Apart from that, SSL 3.0 is more extensible and offers extra features:

• SSL 3.0 supports more generic key exchange mechanisms, such as Diffie-Hellman (SSL 2.0 is RSA-only). In particular, this opens the possibility of ephemeral Diffie-Hellman, which grants forward secrecy, a nice thing to have.
• SSL 3.0 allows for re-handshake: doing a new handshake within the context of the first. This allows for things such as requesting certificate-based client authentication conditionally, based on what was previously exchanged over the connection.
• SSL 3.0 supports optional compression (not always a good idea, but sometimes a nice thing to have).
• SSL 3.0 is extensible with room to put extensions in the ClientHello and ServerHello. This has been used extensively, e.g. to fully support elliptic-curve cryptography.

RFC 6176 lists four reasons why SSL 2.0 must not be used, in its section 2:

• Message authentication uses MD5 [MD5]. Most security-aware users have already moved away from any use of MD5 [RFC6151].

• Handshake messages are not protected. This permits a man-in-the- middle to trick the client into picking a weaker cipher suite than it would normally choose.

• Message integrity and message encryption use the same key, which is a problem if the client and server negotiate a weak encryption algorithm.

• Sessions can be easily terminated. A man-in-the-middle can easily insert a TCP FIN to close the session, and the peer is unable to determine whether or not it was a legitimate end of the session.

However not all reasons are equivalent in gravity. The main security issue with SSL 2.0 is that it has no notion of verified closure: the SSL 2.0 connection ends when the underlying TCP connection is closed. An active attacker can force that, and neither client nor server can know whether the closure is really what the peer wanted. This is a problem when the protocol within the SSL tunnel uses the closure in a semantic way; e.g., with HTTP when there is no Content-Length header or chunked encoding (a rarity nowadays).

The three other reasons are less imperious, and can be debated:

• Though MD5 is thoroughly broken with regards to collisions, it still is quite strong when used in other ways, e.g. to build a MAC (as long as you do it properly). You should not use MD5 in new designs, but that does not mean that MD5, as it is used in SSL 2.0, can trivially be broken (or even non-trivially).
• Through the lack of protection of the handshake messages, attackers can force client and server to use a weaker cipher suite than what they could have used -- but one could say that the real issue here is that the client and server agree to use a weak cipher suite at all.
• Indeed, when the negotiated encryption is weak (a 40-bit "export cipher"), the MAC key is equally weak. But, there again, if the client and server agree to use weak crypto, they only get what they deserve.

Apart from that, SSL 3.0 is more extensible and offers extra features:

• SSL 3.0 supports more generic key exchange mechanisms, such as Diffie-Hellman (SSL 2.0 is RSA-only). In particular, this opens the possibility of ephemeral Diffie-Hellman, which grants forward secrecy, a nice thing to have.
• SSL 3.0 allows for re-handshake: doing a new handshake within the context of the first. This allows for things such as requesting certificate-based client authentication conditionally, based on what was previously exchanged over the connection.
• SSL 3.0 supports optional compression (not always a good idea, but sometimes a nice thing to have).
• SSL 3.0 is extensible with room to put extensions in the ClientHello and ServerHello. This has been used extensively, e.g. to fully support elliptic-curve cryptography.