Skip to main content
Information Security

Return to Answer

replaced http://tools.ietf.org/html/rfc with https://www.rfc-editor.org/rfc/rfc
Source Link
Community Bot
Community Bot
  • 1

In "normal" SSL, the client announces what it supports (versions, algorithms), and the server responds with what will be used for the connection. There is something special with SSLv2, though. If:

  • the client starts by sending a ClientHello in SSLv2 format, and
  • the server agrees with doing SSLv2 (e.g. because the client announced that it supports only SSLv2, or the server supports only SSLv2),

then the algorithm negotiation follows the SSLv2 style in which both client and server send their list of supported algorithms, and the client chooses.

In any case, there won't be an algorithm or protocol version which will be used unless both client and server agree to use them. Moreover, at least with SSLv3 and ulterior, the client sends an ordered list of preferred algorithms, and it will not put weak cipher suites first. So, in practice, client and server will accept to use SSLv2 and/or a weak cipher suite only if both support them and there is no better version or cipher suite that they both support. So this does not happen often; and if it does happen then it could be argued that SSLv2 or a weak cipher suite is better than not being able to connect at all.

(Note: there is a technical detail about SSLv2, though. In SSLv2, an attacker can force client and server to agree on a weak cipher suite even if they both support strong cipher suites. However, if both client and server support SSLv3 or TLS in addition to SSLv2, then the attacker cannot force them to use SSLv2. See section E.2 of TLS 1.0TLS 1.0.)

Therefore, there is no absolute requirement of disabling SSLv2 on the clients. However, it is better to move away from SSLv2 (should have been done already a decade ago); there is a RFCa RFC on that subject.

Browser vendors have not waited for that. For instance, IE 8.0 disables SSL 2.0 support by default on the client. It can be re-enabled, but it can be assumed that almost nobody did that, and the Web did not implode. Similarly, Chrome dropped support of SSL 2.0 since version 10, and recent versions of Firefox don't support it either. You might be, in fact, a little late in the SSLv2-haters crowd. The World has moved to SSL 3.0 and TLS.

As for weak cipher suites, they will be used only if there is no better choice, and 56-bit DES is still better than no encryption at all, so I say: let them live.

In "normal" SSL, the client announces what it supports (versions, algorithms), and the server responds with what will be used for the connection. There is something special with SSLv2, though. If:

  • the client starts by sending a ClientHello in SSLv2 format, and
  • the server agrees with doing SSLv2 (e.g. because the client announced that it supports only SSLv2, or the server supports only SSLv2),

then the algorithm negotiation follows the SSLv2 style in which both client and server send their list of supported algorithms, and the client chooses.

In any case, there won't be an algorithm or protocol version which will be used unless both client and server agree to use them. Moreover, at least with SSLv3 and ulterior, the client sends an ordered list of preferred algorithms, and it will not put weak cipher suites first. So, in practice, client and server will accept to use SSLv2 and/or a weak cipher suite only if both support them and there is no better version or cipher suite that they both support. So this does not happen often; and if it does happen then it could be argued that SSLv2 or a weak cipher suite is better than not being able to connect at all.

(Note: there is a technical detail about SSLv2, though. In SSLv2, an attacker can force client and server to agree on a weak cipher suite even if they both support strong cipher suites. However, if both client and server support SSLv3 or TLS in addition to SSLv2, then the attacker cannot force them to use SSLv2. See section E.2 of TLS 1.0.)

Therefore, there is no absolute requirement of disabling SSLv2 on the clients. However, it is better to move away from SSLv2 (should have been done already a decade ago); there is a RFC on that subject.

Browser vendors have not waited for that. For instance, IE 8.0 disables SSL 2.0 support by default on the client. It can be re-enabled, but it can be assumed that almost nobody did that, and the Web did not implode. Similarly, Chrome dropped support of SSL 2.0 since version 10, and recent versions of Firefox don't support it either. You might be, in fact, a little late in the SSLv2-haters crowd. The World has moved to SSL 3.0 and TLS.

As for weak cipher suites, they will be used only if there is no better choice, and 56-bit DES is still better than no encryption at all, so I say: let them live.

In "normal" SSL, the client announces what it supports (versions, algorithms), and the server responds with what will be used for the connection. There is something special with SSLv2, though. If:

  • the client starts by sending a ClientHello in SSLv2 format, and
  • the server agrees with doing SSLv2 (e.g. because the client announced that it supports only SSLv2, or the server supports only SSLv2),

then the algorithm negotiation follows the SSLv2 style in which both client and server send their list of supported algorithms, and the client chooses.

In any case, there won't be an algorithm or protocol version which will be used unless both client and server agree to use them. Moreover, at least with SSLv3 and ulterior, the client sends an ordered list of preferred algorithms, and it will not put weak cipher suites first. So, in practice, client and server will accept to use SSLv2 and/or a weak cipher suite only if both support them and there is no better version or cipher suite that they both support. So this does not happen often; and if it does happen then it could be argued that SSLv2 or a weak cipher suite is better than not being able to connect at all.

(Note: there is a technical detail about SSLv2, though. In SSLv2, an attacker can force client and server to agree on a weak cipher suite even if they both support strong cipher suites. However, if both client and server support SSLv3 or TLS in addition to SSLv2, then the attacker cannot force them to use SSLv2. See section E.2 of TLS 1.0.)

Therefore, there is no absolute requirement of disabling SSLv2 on the clients. However, it is better to move away from SSLv2 (should have been done already a decade ago); there is a RFC on that subject.

Browser vendors have not waited for that. For instance, IE 8.0 disables SSL 2.0 support by default on the client. It can be re-enabled, but it can be assumed that almost nobody did that, and the Web did not implode. Similarly, Chrome dropped support of SSL 2.0 since version 10, and recent versions of Firefox don't support it either. You might be, in fact, a little late in the SSLv2-haters crowd. The World has moved to SSL 3.0 and TLS.

As for weak cipher suites, they will be used only if there is no better choice, and 56-bit DES is still better than no encryption at all, so I say: let them live.

Source Link
Tom Leek
Tom Leek
  • 173.8k
  • 29
  • 352
  • 483

In "normal" SSL, the client announces what it supports (versions, algorithms), and the server responds with what will be used for the connection. There is something special with SSLv2, though. If:

  • the client starts by sending a ClientHello in SSLv2 format, and
  • the server agrees with doing SSLv2 (e.g. because the client announced that it supports only SSLv2, or the server supports only SSLv2),

then the algorithm negotiation follows the SSLv2 style in which both client and server send their list of supported algorithms, and the client chooses.

In any case, there won't be an algorithm or protocol version which will be used unless both client and server agree to use them. Moreover, at least with SSLv3 and ulterior, the client sends an ordered list of preferred algorithms, and it will not put weak cipher suites first. So, in practice, client and server will accept to use SSLv2 and/or a weak cipher suite only if both support them and there is no better version or cipher suite that they both support. So this does not happen often; and if it does happen then it could be argued that SSLv2 or a weak cipher suite is better than not being able to connect at all.

(Note: there is a technical detail about SSLv2, though. In SSLv2, an attacker can force client and server to agree on a weak cipher suite even if they both support strong cipher suites. However, if both client and server support SSLv3 or TLS in addition to SSLv2, then the attacker cannot force them to use SSLv2. See section E.2 of TLS 1.0.)

Therefore, there is no absolute requirement of disabling SSLv2 on the clients. However, it is better to move away from SSLv2 (should have been done already a decade ago); there is a RFC on that subject.

Browser vendors have not waited for that. For instance, IE 8.0 disables SSL 2.0 support by default on the client. It can be re-enabled, but it can be assumed that almost nobody did that, and the Web did not implode. Similarly, Chrome dropped support of SSL 2.0 since version 10, and recent versions of Firefox don't support it either. You might be, in fact, a little late in the SSLv2-haters crowd. The World has moved to SSL 3.0 and TLS.

As for weak cipher suites, they will be used only if there is no better choice, and 56-bit DES is still better than no encryption at all, so I say: let them live.