As it stands, all ciphers supported by SSLv3 are vulnerable: * The RC4 ciphers are vulnerable to statistical analysis (bar mitzvah attack) * The FORTEZZA, RC2, IDEA and DES ciphers are vulnerable to collisions for having too small block size (SWEET32 attack). * The FORTEZZA, RC2, IDEA and DES and AES ciphers are only supported in CBC mode which is vulnerable to the POODLE (and BEAST) attacks using padding oracles. * The propossed RFC 7568 elaborates more on these issues https://tools.ietf.org/html/rfc7568 SSLV2 is not better than this with issues like DROWN present. Because of this I'd like to recommend that we provide a safe default in our profiles and disable these USE flags. Users can enable them manually if they need them for some reason. (Thanks to txt-file for pointing this out in IRC)
If some package is enabling sslv2 or sslv3 (whose flaws are well-known by now) by default, then wouldn't it make more sense to ask those maintainers to stop? That is, to change "+sslv2" to simply "sslv2". Any package that requires either one should probably have a security bug at this point.
Hasn't libressl-2.6.0 disabled ssl-3 already? There is a bug of libressl about stabilisation!
(In reply to Michael Orlitzky from comment #1) > If some package is enabling sslv2 or sslv3 (whose flaws are well-known by > now) by default, then wouldn't it make more sense to ask those maintainers > to stop? That is, to change "+sslv2" to simply "sslv2". Any package that > requires either one should probably have a security bug at this point. sslv2 isn't enabled by any packages on the portage tree but sslv3 is (which is what prompted this to start with). The foollowing packages have +sslv3 in their IUSE: =dev-libs/openssl-1.0.2k =dev-libs/openssl-1.0.2l =net-libs/gnutls-3.5.12 =net-libs/gnutls-3.5.13 =net-libs/gnutls-3.5.14 And there might be also some overlays doing the same as SSL3 is usually enabled to ensure backwards compatibility with ancient systems.
Keep in mind that the stable openssl versions are also affected by this.
OpenSSL has phased out these flags, and they're disabled by default in the current stable releases. GnuTLS has also disabled them by default, but the flags remain in newer versions. I'm not sure there's anything left to do though since you have to go out of your way to enable them. Five years later, it might be appropriate to throw them in the top-level package.use.mask for good measure. Disabling things that have been known to be exploitable for over a decade isn't exactly "hardening." This would benefit naive users who are afraid to disable anything that says "ssl."
The only packages that have these flags have them masked in base/package.use.mask now.
