Support for SSLv3 and RC4 disabled in *luci*
The use of the insecure SSLv3 protocol and RC4 algorithm has been disabled in *luci*, the web-based high availability administration application. By default, only TLSv1.0 and higher protocol versions are allowed, and the digest algorithm used for self-managed certificates has been updated to SHA256. It is possible to re-enable SSLv3 (by uncommenting the `allow_insecure` options in relevant sections of the `/etc/sysconfig/luci` configuration file), but that is only for unlikely and unpredictable cases and should be used with extreme caution.
This update also adds the possibility to adjust the most important SSL/TLS properties (in addition to the mentioned `allow_insecure`): the path to the certificate pair and the cipher list. These settings can be used either globally, or independently for both secure channels (HTTPS web UI access and connection with *ricci* instances).
DescriptionJan Pokorný [poki]
2014-10-23 17:44:45 UTC
Due to an ever-increasing attention being paid to minimal acceptable
version of SSL/TLS and/or their ciphers (security scanners, etc.)
and because luci-<web interface client/browser> communication should
be just fine with TLS1.0+ nowadays.
While the original [bug 991575] conditionally disables SSLv2, I think
we should:
- treat SSLv3 the same as SSLv2
- invert the respective default: go secure and allow to revert to
previous behavior (for rather
obscure use cases)
To be noted that relying merely on security scanners tends to provide
false sense of overall security; certificate management (conga, as in
ricci+luci, using self-signed ones with limited options to roll up custom
ones) is perhaps comparably weak point here (see also [bz885028]).
+++ This bug was initially created as a clone of Bug #991575 +++
--- Additional comment from Jan Pokorný on 2014-10-15 20:06:08 CEST ---
"Almost" in time to allow for SSLv3 blocking:
https://securityblog.redhat.com/2014/10/15/poodle-a-ssl3-vulnerability-cve-2014-3566/http://fedoramagazine.org/what-you-need-to-know-about-the-sslv3-poodle-flaw-cve-2014-3566/
[...]
[ If the patch was going to be revisited now, I'd probably guard against
using SSLv3 along SSLv2 with the established "ssl_allow_insecure"
option in the same sysconfig file. ]
--- Additional comment from Jan Pokorný on 2014-10-15 23:19:18 CEST ---
[...]
Due to point at the release cycle, viable option is live-patching luci
and making sure "ssl_allow_insecure" is commented out as it could have
been set to "true" while "ssl_cipher_list" has to be uncommented.
# cd "$(ls -1d /usr/lib*/python*/site-packages/luci)"
# patch <<EOF
--- initwrappers.py 2014-10-15 22:52:46.239999612 +0200
+++ initwrappers.py 2014-10-15 22:53:02.273000007 +0200
@@ -128,6 +128,7 @@
if ssl_allow_insecure in ('', 'false', False):
# XXX note that SSL.OP_NO_COMPRESSION is missing
ssl_context.set_options(SSL.OP_NO_SSLv2)
+ ssl_context.set_options(SSL.OP_NO_SSLv3)
ssl_context.use_privatekey_file(ssl_pem)
ssl_context.use_certificate_chain_file(ssl_pem)
ssl_context.set_cipher_list(ssl_cipher_list)
EOF
# sed -i.1 's|^[#]\?\(ssl_cipher_list\s*=.*\)|\1|' /etc/sysconfig/luci
# sed -i.2 's|^[#]\?\(ssl_allow_insecure\s*=.*\)|#\1|' /etc/sysconfig/luci
# service luci restart
Comment 9Jan Pokorný [poki]
2016-01-07 22:45:08 UTC
Hi Jan,
I edited the Doc Text field to form a short note for Release Notes. Could you please have a quick look?
Comment 16Jan Pokorný [poki]
2016-04-11 14:46:00 UTC
Roberte,
I am not sure to what extend we want to abstract the details out of
the picture, and also not sure we should sacrifice information that
some properties of the two secure channels are, since this update,
configurable independently.
If there's no confict in requirements, I would append a sentence like
this:
New is also the possibility to adjust most important SSL/TLS properties
(beside mentioned "allow insecure" override: path to certificate pair,
cipher list) either globally, or independently for both secure channels
(HTTPS for web UI access + connection with ricci instances), and the
digest algorithm used for self-managed certificate is updated to SHA256.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://rhn.redhat.com/errata/RHBA-2016-0892.html