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.

  • 1
    So...You want us to write your presentation for you? – Xander May 1 '14 at 19:15
  • Not really. I just want an explanation of at least one method used by an attacker and that's it. I have all the other parts done. – user3585363 May 1 '14 at 19:18
  • 3
    I just did a Google search and came up with a lot of material specifically for your question. Assuming that you have done the same search, can you re-write your question with the specific things you did not understand in what you read? – schroeder May 1 '14 at 19:27
  • ^^ Basically, the way the attack is done and the ways an attacker could get privilege in a website with the vul. – user3585363 May 1 '14 at 19:45
  • SSL 2 can't be that bad--my bank use it ssllabs.com/ssltest/analyze.html?d=lloydsbank.com – Colonel Panic Nov 17 '15 at 16:39

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

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.

  • 1
    The point is that I included one of the current websites(with rights from admin) that currently uses SSL 2.0 in the research. Every time I scan the website using acunetix to see whether any vulz exist, it shows "SSL 2.0 deprecated protocol" with a sign that shows it is a high alert and serious problem. How may it be argued that the issue no longer applies if they still have it listed in acunetix as a high alert? Is it that acunetix just didn't update their info or could the site still be vulnerable? – user3585363 May 1 '14 at 19:38
  • 2
    Acunetix lives and strives by how many "vulnerabilities" it can warn about. If Tradition has it that some feature is dangerous, then Acunetix MUST detect and warn about it, otherwise its competitors would point and laugh at them. SSL 2.0 is declared "dangerous" because it has a longstanding reputation of being dangerous. – Tom Leek May 1 '14 at 19:48
  • I get it now. Your help in answering is deeply appreciated btw. Thanks a lot! You really got me into heading in the right way at this research. – user3585363 May 1 '14 at 19:51

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.