Bug 1578412
| Summary: | [BLOCKED] ovirt-imageio TLS hardening (TLS version and cipher suite) | ||
|---|---|---|---|
| Product: | [oVirt] ovirt-imageio | Reporter: | Nir Soffer <nsoffer> |
| Component: | General | Assignee: | Nir Soffer <nsoffer> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Jiri Belka <jbelka> |
| Severity: | urgent | Docs Contact: | |
| Priority: | high | ||
| Version: | 1.2.2 | CC: | bugs, danken, dmoppert, jbelka, kseifried, nsoffer, pstehlik, tmraz, tnisan, ykaul, ylavi |
| Target Milestone: | ovirt-4.2.4 | Keywords: | Improvement |
| Target Release: | --- | Flags: | rule-engine:
ovirt-4.2+
|
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | ovirt-imageio-common-1.4.0 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | 1577594 | Environment: | |
| Last Closed: | 2018-06-26 08:44:07 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | Storage | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1584545 | ||
| Bug Blocks: | 1577594 | ||
|
Description
Nir Soffer
2018-05-15 14:06:31 UTC
Kurt, can we get recommendation from the security team about changing the ciphers? should we keep the default Python ciphers list, or use the recommended value from the TLS hardening guide? See comment 0 for more details. (In reply to Nir Soffer from comment #0) > 3. Regarding the ciphers, not sure if we need to override Python default, > the configuration recommended by the seems to allow less ciphers. > we need a recommendation from RHEL security team on this. I've asked rhel-crypto@ to comment on the importance of limiting the cipher list per hardening guide. Note this cipher list seems to come from rhel-8 or Fedora (2.7.13+): > _RESTRICTED_SERVER_CIPHERS = ( > 'ECDH+AESGCM:ECDH+CHACHA20:DH+AESGCM:DH+CHACHA20:ECDH+AES256:DH+AES256:' > 'ECDH+AES128:DH+AES:ECDH+HIGH:DH+HIGH:RSA+AESGCM:RSA+AES:RSA+HIGH:' > '!aNULL:!eNULL:!MD5:!DSS:!RC4:!3DES' > ) rhel-7's (python 2.7.5) list is different: > _RESTRICTED_SERVER_CIPHERS = ( > 'ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+HIGH:' > 'DH+HIGH:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+HIGH:RSA+3DES:!aNULL:' > '!eNULL:!MD5:!DSS:!RC4' > ) See <http://opengrok.brq.redhat.com/source/xref/RHEL-7/python/2.7.5/68.el7/Python-2.7.5/Lib/ssl.py#174> or `python -c 'import ssl; print ssl._RESTRICTED_SERVER_CIPHERS'` The question is how much interoperable you want to be. The differences in the two cipher lists are that the Python default additionally contains the non-PFS ciphersuites and CAMELLIA ciphersuites. As they are sorted properly with the non-PFS ciphersuites last, I do not see any particular problem with the Python default list. To complete this change, we require bug 1581901, removing 3DES from the python default cipher suite. We have ovirt-imageio-proxy -> ovirt-imageio-daemon communication. I tried to upload a disk with updated python on engine (ie. ovirt-imageio-proxy) and I did not see any 3DES in Cipher Suites list, although the communication is TLSv1.0/2 -> TLSv1.2 in the end. When I tried the same with non-updated python I see in ovirt-imageio-proxy's ClientHello 'TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)'. In both cases final protocol was TLSv1.2 and 'TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384' cipher suite. ovirt-imageio-daemon-1.3.1.2-0.el7ev.noarch python-2.7.5-69.el7_5.x86_64 ovirt-imageio-proxy-1.3.0-0.el7ev.noarch python-2.7.5-69.el7_5.x86_64 (In reply to Nir Soffer from comment #0) > Current configuration > --------------------- > > Since ovirt-imageio-1.1.0 (ovirt-4.2), both ovirt-imageio-daemon and > ovirt-imageio-proxy support only TLSv1.1 and TLSv1.2. I don't know enough about TLS but this is what I see in wireshark for engine's ovirt-image-proxy (ovirt-imageio-proxy-1.3.0-0.el7ev.noarch & non-updated python-2.7.5-68.el7.x86_64) initialized connection on host (dump is from host/server): ... Secure Sockets Layer SSL Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Length: 512 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 508 Version: TLS 1.2 (0x0303) Random gmt_unix_time: May 15, 1988 16:29:27.000000000 CEST random_bytes: bcbc693b74824662f15e7dff993b52e02d6871659947197b... Session ID Length: 0 Cipher Suites Length: 158 Cipher Suites (79 suites) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c) ... Could you please explain if it is TLSv1.0 or TLSv1.2 in first connection from client -> server? (In reply to Jiri Belka from comment #6) > (In reply to Nir Soffer from comment #0) > > > Current configuration > > --------------------- > > > > Since ovirt-imageio-1.1.0 (ovirt-4.2), both ovirt-imageio-daemon and > > ovirt-imageio-proxy support only TLSv1.1 and TLSv1.2. > > I don't know enough about TLS but this is what I see in wireshark for > engine's ovirt-image-proxy (ovirt-imageio-proxy-1.3.0-0.el7ev.noarch & > non-updated python-2.7.5-68.el7.x86_64) ... > Could you please explain if it is TLSv1.0 or TLSv1.2 in first connection > from client -> server? I don't know enough about TLS to tell that by the wireshark dump. However we disable TLSv1.0 on the server side (both proxy and daemon), so The communication cannot be TLSv1.0 and is should be TLSv1.2. You can test that the daemon and proxy do not support TLSv1.0 like this: openssl s_client -connect host:port -tls1 The command will fail to connect. For client connection from proxy to daemon we use the requests library, which uses https://docs.python.org/2/library/ssl.html#ssl.PROTOCOL_TLS So it should select the highest available protocol. (In reply to Nir Soffer from comment #7) > You can test that the daemon and proxy do not support TLSv1.0 like this: > > openssl s_client -connect host:port -tls1 > > The command will fail to connect. > > For client connection from proxy to daemon we use the requests library, > which uses > https://docs.python.org/2/library/ssl.html#ssl.PROTOCOL_TLS > So it should select the highest available protocol. That could explain that it starts with lower version and then both sides agree on higher version. It's not so explicit but our server part doesn't allow TLSv1.0 thus it's ok. This bug is not marked as blocker and we entered blocker only phase for 4.2.4. Please consider re-targeting to 4.2.5. Sandro, the fix is included in the latest build (1.4.0). Since the underlying bug 1581901 is ON_QA, this bug can follow suit. Testers should make sure that they use the proper python-2.7.5-73.el7 (or higher) ok, just highlighting this needs updated python/python-libs from #1581901 (7.5.z)
- proxy part:
-- default
# grep tls /etc/ovirt-imageio-proxy/ovirt-imageio-proxy.conf.sample
# enable_tls1_1 = False
# rpm -q python; for i in tls1 tls1_1 tls1_2 ; do echo $i ; echo "" | openssl s_client -connect 10.37.136.71:54323 -${i} >/dev/null 2>&1 ; echo $? ; done
python-2.7.5-69.el7_5.x86_64
tls1
1
tls1_1
1
tls1_2
0
-- tls1_1 enabled
# grep tls /etc/ovirt-imageio-proxy/ovirt-imageio-proxy.conf
enable_tls1_1 = True
# for i in tls1 tls1_1 tls1_2 ; do echo $i ; echo "" | openssl s_client -connect 10.37.136.71:54323 -${i} >/dev/null 2>&1 ; echo $? ; done
tls1
1
tls1_1
0
tls1_2
0
# python -c 'import ssl; print ssl._RESTRICTED_SERVER_CIPHERS'
ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+HIGH:DH+HIGH:RSA+AESGCM:RSA+AES:RSA+HIGH:!aNULL:!eNULL:!MD5:!DSS:!RC4:!3DES
# rpm -qa ovirt-imageio-proxy
ovirt-imageio-proxy-1.3.0-0.el7ev.noarch
- daemon part:
-- default
# grep tls /etc/ovirt-imageio-daemon/daemon.conf
# enable_tls1_1 = False
# for i in tls1 tls1_1 tls1_2 ; do echo $i ; echo "" | openssl s_client -connect slot-5b:54322 -${i} >/dev/null 2>&1 ; echo $? ; done
tls1
1
tls1_1
1
tls1_2
0
-- tls1_1 enabled
# grep ^enable_tls /etc/ovirt-imageio-daemon/daemon.conf
enable_tls1_1 = True
# for i in tls1 tls1_1 tls1_2 ; do echo $i ; echo "" | openssl s_client -connect slot-5b:54322 -${i} >/dev/null 2>&1 ; echo $? ; done
tls1
1
tls1_1
0
tls1_2
0
ovirt-imageio-daemon-1.4.0-0.el7ev.noarch
This bugzilla is included in oVirt 4.2.4 release, published on June 26th 2018. Since the problem described in this bug report should be resolved in oVirt 4.2.4 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report. |