SSL 2.0 -- 1996 wants its broken protocol back
 

SSL 2.0 has been known to be unsafe for almost 20 years. In fact, this prompted Netscape to develop a completely redesigned
replacement protocol, SSL 3.0, which it released in early 1996.

Modern browsers don't support SSL 2.0 nor do most SSL/TLS libraries. OpenSSL might be the only major SSL/TLS library that still
supports the protocol by default (n.b. OpenSSL's default cipher list doesn't include any SSL 2.0 ciphers though many applications
set their own cipher lists). Mozilla's NSS also contains SSL 2.0 support in its code base but, since NSS 3.13, it is disabled by
default and is planned for complete removal in the near term.

Among the protocol's bigger problems:

• The handshake is vulnerable to MiTM attacks
• MAC construction is weak and relies on MD5
• Weak export-grade ciphers weaken MACs
• Same cryptographic key used for message authentication and encryption
• TCP FIN is taken as EOD permitting truncation attacks

For these reasons, disabling SSL 2.0 is one of the OpenSSL recommendations I make in a security/vulnerability post (note: many
OSes such as Debian, Ubuntu, and OpenBSD build OpenSSL without SSL 2.0).

Caveat utilitor: before making the decision to switch to a non-SSLv2 OpenSSL, it is important to realize things can get a little
messy - Slackware packages that link OpenSSL SSLv2 functions will need to be rebuilt or, possibly, upgraded. A partial list
includes: neon, Python, M2Crypto, curl, php, qt, ruby, wget, fetchmail, stunnel, mailx, httpd.

However, the result is an OS purged of the possibility of unsafe SSL 2.0 usage (at least via OpenSSL).

--mancha

---------
Note: while re-building neon and Python against my SSLv2-less OpenSSL, I realized my personal OpenSSL slackbuild was incorrectly
disabling SSLv2 by defining the OPENSSL_NO_SSL2 macro rather than using "no-ssl2". This prevented the macro from getting defined
in one of OpenSSL's public headers and became an issue when rebuilding programs because they couldn't detect that SSLv2 wasn't
supported.

I mention this for those who are using my slackbuild (contained in openssl-20140605.tar.bz2). The new openssl-20140916.tar.bz2
provides a corrected slackbuild along with the latest OpenSSL source code of the relevant branches (i.e. 1.0.1i and 0.9.8zb).

Once again, thanks for your work.

I have libreSSL installed and I didn't have to rebuild any packages. Should I have ? All I did was make some symlinks and everything works.

Are you sure everything works?

Check libneon by compiling empty.c:

Check Python's ssl module with:

You can fix neon with a re-build (after reading this post). Python will be a little trickier because re-building will only address the
SSL 2.0 issue. If you want to use it with LibreSSL you'll have to patch Python so it doesn't use RAND_egd.

--mancha

Ok, I guess those don't work. I guess I'll have to rebuild all packages just to be sure. Thanks.

stunnel needs upgrade to latest 5.03 due to stunnel: CVE-2013-1762 if you use samba.

What about GNUTLS? I've heard it's actually not as strong as OpenSSL or LibreSSL.

Really good job, mancha. As always.
I'd like to see LibreSSL would completely replace OpenSSL in some of the future Slackware releases.
Here is a partial list of applications and libs Gentoo folks tested for LibreSSL's compatibility. I could add nginx server which seems to work after a decent patch applied.

I couldn't rebuild everything, it's too much. I rebuild as much as I could and created the symlink for the rest to work.

My original post shouldn't be mistaken as a criticism of OpenSSL. Rather, its purpose is to raise awareness about insecure configurations.

But, OpenSSL chooses to support the broken SSL 2.0. Isn't that on them?

OpenSSL has numerous support commitments. Among those, embedded clients that only speak SSL 2.0 (ergo the support). However, I do
think they could flip the logic so SSL 2.0 has to be explicitly enabled (not disabled). Oh, and the bike shed should be blue.

GnuTLS is a feature-rich and mature SSL/TLS tookit that, unlike OpenSSL and LibreSSL, is pretty much a one-man-operation (at least
lately). However, it's not always easy to tell it's developed by a skeleton crew because of its dynamic development process with Nikos
continually expanding the feature set and promptly addressing vulnerabilities as they're identified.

I'm not going to recommend one library over another or get into their relative strengths and weaknesses. Suffice it to say, the
ecosystem is large enough for OpenSSL (and forks such as LibreSSL and BoringSSL) and other mature SSL/TLS suites like GnuTLS. In
fact, the added choice and potential for cross-pollination between projects means we all benefit.

Many thanks for that reminder. I brought this up back in a February post but it's good you bring it up now because it's one of the
packages that require re-building after installing an OpenSSL without SSL 2.0.

That's a great resource - thanks! The good folks at Gentoo have a long tradition of quality documentation and this is one more example.

--mancha