3

Is it a requirement to also disable SSL v2 and weak ciphers on client PC's? I have seen quite a few posts for disabling them on servers, but nothing about a regular client PC, say, running Windows XP or Windows 7.

Improve this question

3 Answers 3

Reset to default
2

You might want to read the three excellent answers to the question How does SSL work, where it's all explained, but in a nutshell, the server will select which ciphersuite (and compression) to use during the SSL/TLS handshake, after it receives supported ciphersuites from the client. Since you removed support of certain weak ciphersuites on your server end, they can't be selected for the SSL/TLS transport encryption, even if they are supported on the client.

Edit to add: As has @DavidHoelzer mentioned in the comment below, not all websites have yet moved to TLS, and you don't want to be punishing your users for that. Even the weaker ciphersuites are better than none at all, if you remove support for them on clients. Your users would most likely still use those websites, even if they couldn't connect to the host using HTTPS, and would end up opting for HTTP, exposing them to many more threats in the process. In short - I wouldn't recommend it.

Improve this answer
1
  • 1
    Two quick points. First, you should expect that the server will attempt to negotiate up to the highest common cipher/protocol supported. This should, hopefully, take you to TLS/1.2. Second, requiring that browsers disable SSLv2 won't matter so much when they connect to you but your users may hate you when they try to connect to the many thousands of sites who have not yet moved to TLS. I know, it's been years, but until people get bitten (or a PCI auditor sits on them for TLS/1.2) they don't seem to react.
    – David Hoelzer
    Commented Jul 15, 2013 at 2:06
2

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.

Improve this answer
0

You would do this per client application.

e.g. in old Firefox

https://www.mozilla.org/security/announce/2007/mfsa2007-06.html

I could not find a way to disable sslv2 in modern firefox. I think it is long gone.

In Chrome, this discussion suggests that sslv2 is disabled by default:

http://productforums.google.com/forum/#!topic/chrome/jH53hxAhVys

And this question has an answer about IE5.5, IE6 and IE7

https://stackoverflow.com/questions/10103635/which-browsers-were-the-last-to-support-only-sslv2

I could not find information about the Safari web browser.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .