By default, OpenSSL is compiled with support for insecure protocols such as SSLv2 and SSLv3, and weak ciphers such as RC4. Many applications using OpenSSL, especially clients, provide no way to customize the protocol options and cipher suite. dev-libs/openssl should provide use flags to disable insecure protocols/ciphers. These can easily be added to the ebuild's ./${config} call, for example: $(use_ssl ssl2) At least SSLv2 should be disabled by default, preferably SSLv3 as well. I don't think we can afford to disable RC4 by default just yet, but the option should at least be there for security-aware users. If you add the use flags, make sure to verify that they actually have an effect because OpenSSL's configure script tends to quietly ignore unknown options. Reproducible: Always Steps to Reproduce: 1. Try to install dev-libs/openssl without support for insecure ciphers. Expected Results: Insecure protocols and/or ciphers are disabled by default in the OpenSSL ebuild.
unfortunately, some services rely on them ... it isn't just a client side issue. these algorithms are also used beyond networking like checking local files. i don't really want to add an explosion of USE flags ... adding a single OPENSSL_ALGOS USE expanded variable doesn't scale well because then you'd have to manually enable all the important ones yourself. either way, i can see this leading to a nightmare of bugs. people wouldn't associate <random gtk/qt/whatever app can't connect> with "i disabled a bunch of random algorithms in openssl". i sympathize with the request, but i'm not sure we have a sane way atm unless we have packages enumerate the algos they use in their RDEPEND. if they even can as some algos are picked on the fly based on the input ...
I agree that this is impractical for the algorithms, but we could at least create USE flags for sslv2 and sslv3, especially now with POODLE around. Probably sslv2 could be turned off completely without a USE flag, and people who really need it for some weird legacy stuff can be pointed to openssl 0.9.8 for now? In terms of use_expand you do something like OPENSSL_BLACKLIST="sslv2 sslv3" to avoid manually maintaining the list of new protocols.
(In reply to Hans de Graaff from comment #2) > Probably sslv2 could be turned off completely without a USE flag, and people > who really need it for some weird legacy stuff can be pointed to openssl > 0.9.8 for now? I don't understand the relation you are drawing between openssl 0.9.8 and SSLv2. Currently, our openssl-0.9.8 ebuilds only install the .so files for pre-built binary packages which need them.
(In reply to Mike Gilbert from comment #3) > Currently, our openssl-0.9.8 ebuilds only install the .so files for > pre-built binary packages which need them. In that case my comment on SSLv2 makes no sense and we should consider a USE flag for it as well.
*** Bug 525652 has been marked as a duplicate of this bug. ***
+*openssl-1.0.2 (23 Jan 2015) + + 23 Jan 2015; Lars Wendler <polynomial-c@gentoo.org> + -openssl-1.0.2_beta3.ebuild, +openssl-1.0.2.ebuild, + +files/openssl-1.0.2-ipv6.patch, +files/openssl-1.0.2-s_client-verify.patch, + -files/openssl-1.0.2_beta2-ipv6.patch, metadata.xml: + Version bump. Removed old. Added "ssl2" USE flag (bug #510798). + There's now a "ssl2" USE flag for openssl-1.0.2 which is off by default. I tried the same with ssl3 but that didn't work as expected.
+*openssl-1.0.2-r1 (23 Jan 2015) + + 23 Jan 2015; Lars Wendler <polynomial-c@gentoo.org> -openssl-1.0.2.ebuild, + +openssl-1.0.2-r1.ebuild, metadata.xml: + Removed "ssl2" USE flag again. Broke ABI and caused some packages to fail + like cmake (bug #537452) and mozilla packages. + Alright, back to the drawing board *sigh*
I installed 1.0.2 with ssl2 disabled. curl and php broke, but recompiling them was enough to fix the brokage.
As I saw in curl's case, the configure script checks for ssl2 support. If it finds it, it will use it. When openssl recompiled without ssl2 support, curl will try to use undefined symbols. But when curl recompiled, the configure script finds out the ssl2 support is missing, and the resulting binary will not try to use it ever again.
1.0.2 with ssl2 disabled broke me at least net-p2p/deluge (tried to re-emerge it, but it failed also due to undefined reference to `SSLv2_client_method’) and a few apps dependent on Qt5 Network library failed to emerge also with the same error.
I've been privately and on my servers been using ebuilds for openssl that disable ssl2 and ssl3 for a while now. It works, but it takes recompiling a whole bunch of packages - and there is no trivial way to find them (I ended up diff-ing the libssl files with and without ssl2/3 and grepped for the function names in /usr/bin and /usr/lib64). I see two ways to proceed: * Have some script that users can run when they changed the use flags and give them a big warn message when they recompile openssl with ssl2/3 disabled. * Try to get all packages that require the old ssl2/3 functions that they can disable them by default or on use flags. Probably lots of work. Not sure what's best here. It's unfortunate, because once you got a system with it disabled it works completely flawless. It's just the transition that's tricky.
How about... create the ssl2 and ssl3 USE flags, but force them to be on? Then create new stage3 tarballs with /etc/portage/profile/use.mask , having -ssl2 and -ssl3 in them. With this, new systems will be properly built without insecure protocol support. This also gives a possibility to people with existing systems, who willing to rebuild their whole system to get rid of these, but also familiar with the risks of overriding forced USE flags. Comments on this?
You further improve the default security one may alter the DEFAULT_CIPHER_LIST in the openssl build: sed -i 's/^\(#define SSL_DEFAULT_CIPHER_LIST\t\).*/\1"ALL:!aNULL:!eNULL:!SSLv2:!EXPORT:!LOW:!MEDIUM:!RC4:!3DES:!DSS"/' ssl/ssl.h or even set DEFAULT_CIPHER_LIST to prefer forward secrecy in a smart way: prefer eGCM to eAES to all the rest use privacy && ( sed -i 's/^\(#define SSL_DEFAULT_CIPHER_LIST\t\).*/\1"EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EDH+aRSA+AESGCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EDH+SHA256:EECDH+ECDSA:EECDH+aRSA:EDH+aRSA:ALL:!aNULL:!eNULL:!EXPORT:!LOW:!MEDIUM:!RC4:!3DES:!PSK:!SRP:!DSS"/' ssl/ssl.h This single step helps all the packages relying on the DEFAULT_CIPHER_LIST.
Created attachment 401082 [details] ebuild modifying the DEFAULT_CIPHER_LIST in the openssl build
Created attachment 439716 [details, diff] Allow user to configure ciphers used I've also been running with a modified ebuild for a while, disabling many of the older insecure protocols and ciphers. The main ones applications tend to fall over on are DES and RC4, the former because it's still used via 3DES and the latter because it tends to be used in a few Microsoft protocols. The attached patch goes for optimum configurability, while keeping DES and RC4 on by default so to minimise any effect on dependent applications. To reduce the USE explosion, I feel Camellia could be left on unconditionally and IDEA, MDC2, RC2 and maybe RC5 could all be off unconditionally. The build was actually turning IDEA, MDC2 and RC5 on explicitly, while OpenSSL defaults to having them off. Both IDEA and RC5 have known compromises and MDC2 isn't widely used. DES and RC4 should be optional, while defaulting to on, so those who are interested, and willing to deal with the fallout, can disable these. Both ciphers are being phased out and it's likely more will want to get rid of them in the future, particularly RC4.
Created attachment 439718 [details, diff] Fix OpenSSL build without DES The attached patch is needed for OpenSSL to build without DES.
at this time, we're not going to add options that mess with the ABI. the latest version has flags for SSLv2 & SSLv3 because they can be disabled while keeping the ABI intact.