Why is the deprecated SSL 2.0 protocol considered insecure and how can it be exploited?

Question

I am making a presentation to the class about "SSL 2.0 deprecated protocol" and I really have no idea how this exploit is used or how the attacker can use this vul. I understand the impact of this vul, but I need a complete explanation on how it works out and the steps that an attacker would approach to conduct man-in-the-middle attacks or decrypt communications between the affected service and clients. Please explain the process that an attacker can use in a specific explanation if possible.

Answer 1

SSL 2.0 is not a vulnerability; it is a protocol which happens to contain structural vulnerabilities, and, as such, should not be allowed.

There is a RFC which says just that, and lists the main known deficiencies in SSL 2.0:

SSL version 2.0 [SSL2] deficiencies include the following:

o  Message authentication uses MD5 [MD5].  Most security-aware users

   have already moved away from any use of MD5 [RFC6151].

o  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.

o  Message integrity and message encryption use the same key, which

   is a problem if the client and server negotiate a weak encryption
   algorithm.

o  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.

Of the four, only the last one is really a structural serious issue with the protocol. Indeed:

• Though MD5 is broken with regards to collisions, it is still quite strong for other usages, including how it is used in SSL 2.0 to protect integrity.

• When an attacker tricks client and server to use a weak cipher suite, the real problem is not that the attacker can trick the client and the server; it is that the client and server actually agree to use a weak cipher suite.

• The point about using the same key for encryption and integrity makes sense, again, only if the client and server agree to use weak encryption. This could happen in older days because of compliance with the US export regulations, but this has all disappeared since year 2000.

• The lack of verified termination is a problem when the SSL is used to convey a protocol where messages are not self-terminated. A typical case is HTTP 0.9: the client knows that it has obtained the complete file because the server closes the connection. With SSL 2.0, an active attacker can force an early connection close and the client has no way to know whether this is the genuine end-of-file, or a malicious truncate.

  One may argue that with modern HTTP, this issue no longer applies.

So, in fact, if a client and server use SSL 2.0 right now (May 2014), then chances are that this is not an actual problem (or, at least, not the biggest security problem). The real reason why SSL 2.0 is banned is that it has been deprecated for a long time (since 1996 and the invention of SSL 3.0), so any use of SSL 2.0 indicates that some of the involved software has not been updated for at least that long -- and that is a problem. SSL 2.0 is a glorified canary.

Or, said otherwise, using or even allowing SSL 2.0 reveals you as a sloppy, outdated, untrendy sysadmin.