Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

What SSL options should be avoided, due to recently discovered weaknesses? This might include symmetric algorithms, or MAC functions.

share|improve this question

3 Answers 3

up vote 7 down vote accepted

You should avoid the "weak" cipher suites:

  • Cipher suites with no encryption (with a NULL in the name).
  • Cipher suites with 40-bit or 56-bit symmetric keys (DES, DES40, RC4_40, RC2_CBC_40)(3DES is fine, though).
  • Cipher suites marked "for export" (with EXPORT in the name: they are weakened to comply with pre-2000 US export regulations).
  • Cipher suites with no server authentication (DH_anon).

No sane software will enable these by default, or at all. But it is safer to check explicitly...

You may want to avoid RC4 because of the bad press (it still takes some millions of connections with the same encrypted data to hit the known weaknesses, which is not a huge security margin, but the attack is not really practical yet). Some people want to avoid CBC-based block ciphers because they fear the BEAST, but it does not work any more. Similarly, use of MD5 in SSL/TLS is safe, but the idea that "MD5 is broken" is so widespread that using MD5 tends to trigger questions and justifications and endless debate. In practice, your system won't be broken into because you used RC4 or MD5 or AES-CBC or any other non-weak cipher suite; we are in the realm of public relations here.

Among possible options, you should avoid compression unless you make sure that it does not apply to your exact context; this is because encryption hides data contents but not data length, and compression makes length dependent on the contents. In a Web context (HTTPS), this is called the CRIME attack.

If possible (depending on your server software and server certificate), try to use the DHE cipher suites: they provide Perfect Forward Secrecy. Said otherwise: if you use a non-DHE cipher suite, and some bad guy manages to steal your server private key, then he will be able to decrypt past connections (connections which the attacker observed passively, from the outside, before the actual key theft). PFS is about avoiding that. (But, of course, PFS or not PFS, it is much better if your server private key is not stolen at all.)

Don't use SSL 2.0. In practice, SSL 2.0 still offers some decent protection against passive attackers, but active attackers can play nasty tricks. If your client and server software supports SSL 2.0 but not SSL 3.0 or TLS (1.0 or ulterior), then your software is more than 15 years old and almost certainly has a lot of other problems.

share|improve this answer

In addition to above answers, one of the services you can use is https://www.ssllabs.com/ssltest/ , which will test the SSL/TLS settings and right away report you of violations. This way you can quickly audit your settings quickly (Unless you have some scripts ready to do so).

Note : I am no way associated with SSLLabs.

share|improve this answer

The RC4 option should not be used.

Not only is it old (from 1987, ancient even), but it is also suffering from minor security problems.

Still is it often enabled since other (more modern and heavier attacked) algorithms recently got bad news. RC4 is somewhat predictable though and repeatedly (say 20 thousand times) requesting the same webpages via https will show patterns, thus allowing you to compromise security.

[Edit] Added link to attack-of-week-rc4-is-kind-of-broken-in.html

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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