What is the main reason (attacks) the appearance of the protocol SSL version 2.0 to replace version 3.0?
$\begingroup$
$\endgroup$
Add a comment
|
2 Answers
$\begingroup$
$\endgroup$
4
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
ClientHelloandServerHello. This has been used extensively, e.g. to fully support elliptic-curve cryptography.
answered Jan 18, 2014 at 17:35
-
$\begingroup$ what was the change in SSL 3 that did not succumb to this TCP FIN attack? $\endgroup$ Commented Jan 19, 2017 at 9:11
-
1$\begingroup$ SSL 3 and later have a specific alert message (
close_notify) that marks the end of the connection. That message is encrypted and integrity-protected, so an attacker cannot fake it. This allows the receiver to distinguish between a voluntary close from the peer, and a TCP-level FIN or RST. The sad fact that many existing, deployed servers do not send theclose_notify, and many existing deployed client do not mind about the lack ofclose_notify, is another issue. $\endgroup$ Commented Jan 19, 2017 at 13:42 -
$\begingroup$ but a TCP implementation would close the connection anyway after receipt of a TCP FIN right? So maybe your implementation could tell you that something is wrong, but I doubt there are any implementations doing that out there. $\endgroup$ Commented Jan 20, 2017 at 12:19
-
$\begingroup$ and I guess the fact that not many implementations send the
close_notifymeans that wasn't such a big failure of SSL 3 in the end. $\endgroup$ Commented Jan 20, 2017 at 12:19
$\begingroup$
$\endgroup$
Something tells me you didn't put much research effort into this one.
Let me quote part of a distantly related Crypto.SE question by @D.W.:
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.
