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
- 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:
[ 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
# 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
Created attachment 1112626 [details]
I edited the Doc Text field to form a short note for Release Notes. Could you please have a quick look?
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,
If there's no confict in requirements, I would append a sentence like
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.
Thanks for your help with the RN text, Jan.
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.