2 Answers
2

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 included special mitigations to prevent protocol downgrade attacks where a man-in-the-middle downgraded two SSL3-capable endpoints so they end up using SSL 2. This protection in SSL 3 was critical, because SSL 2 had some major problems, and if you could downgrade both endpoints to SSL 2, nasty attacks would have become possible. Happily, the SSL 3 designers anticipated this risk in advance and made sure to introduce a special mechanism in the protocol to prevent "downgrade-to-SSL2" attacks.

Can't add much to that one since it wraps it up rather nicely while skipping the need to bluntly list all individual v2 problems that were fixed by v3. Comparing both protocols will enable you to learn about the fixed issues yourself.

In fact, any search engine will enable you to find references to both protocols, as well as a truckload of papers related to discovered security weaknesses that v2 incorporates. Also, the answers to the linked question contain large chunks of usefull, related information you might want to check out.