Bug 1156167 - luci still agrees on SSLv2 and SSLv3 connections with a web interface client/browser by default
Summary: luci still agrees on SSLv2 and SSLv3 connections with a web interface client/...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: luci
Version: 6.4
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Jan Pokorný [poki]
QA Contact: cluster-qe@redhat.com
Robert Krátký
URL:
Whiteboard:
Depends On: 991575
Blocks: 1156187 1236730 1271835
TreeView+ depends on / blocked
 
Reported: 2014-10-23 17:44 UTC by Jan Pokorný [poki]
Modified: 2019-10-10 09:27 UTC (History)
21 users (show)

Fixed In Version: luci-0.26.0-78.el6
Doc Type: Enhancement
Doc Text:
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).
Clone Of: 991575
: 1156187 1236730 (view as bug list)
Environment:
Last Closed: 2016-05-11 00:16:48 UTC
Target Upstream Version:


Attachments (Terms of Use)
Proposed patch (4.18 KB, patch)
2016-01-07 22:45 UTC, Jan Pokorný [poki]
no flags Details | Diff


Links
System ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 2020483 None None None Never
Red Hat Knowledge Base (Solution) 2273211 None None None 2016-04-22 17:14:40 UTC
Red Hat Product Errata RHBA-2016:0892 normal SHIPPED_LIVE luci bug fix and enhancement update 2016-05-10 22:49:50 UTC

Description Jan 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 9 Jan Pokorný [poki] 2016-01-07 22:45:08 UTC
Created attachment 1112626 [details]
Proposed patch

Comment 15 Robert Krátký 2016-04-11 13:51:03 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 16 Jan 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.

Comment 17 Robert Krátký 2016-04-12 07:25:15 UTC
Thanks for your help with the RN text, Jan.

Comment 19 errata-xmlrpc 2016-05-11 00:16:48 UTC
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


Note You need to log in before you can comment on or make changes to this bug.