Description of problem: Currently it appears that VDSM does not support TLSv1.2. Also, other aspects within RHEV should be checked too, e.g. libvirtd, Spice, qemu-kvm. Version-Release number of selected component (if applicable): RHEV 4.x. How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
The customer needs to implement TLS 1.1+ to be compliant with the payment card industry (PCI). This post says the date to implement TLS 1.2 support is June 30 2018: Date Change for Migrating from SSL and Early TLS https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls
See also: https://bugzilla.redhat.com/show_bug.cgi?id=1387996#c7
I tested the support and when updating engine protocol version to TLSv1.2 and applying vdsm patch I see that it is possible to use this version of the protocol. There are 2 glitches: - we need to switch to std ssl module as default - engine using tlsv1 is not able to talk to vdsm with 1.2 set. This is visible as: 2017-01-11 15:37:36,103+01 INFO [stdout] (SSL Stomp Reactor) SSL Stomp Reactor, READ: TLSv1 Alert, length = 2 2017-01-11 15:37:36,103+01 INFO [stdout] (SSL Stomp Reactor) SSL Stomp Reactor, RECV TLSv1.2 ALERT: fatal, protocol_version 2017-01-11 15:37:36,103+01 INFO [stdout] (SSL Stomp Reactor) SSL Stomp Reactor, fatal: engine already closed. Rethrowing javax.net.ssl.SSLException: Received fatal alert: protocol_version 2017-01-11 15:37:36,103+01 INFO [stdout] (SSL Stomp Reactor) SSL Stomp Reactor, fatal: engine already closed. Rethrowing javax.net.ssl.SSLException: Received fatal alert: protocol_version
We have found out that m2crypto library doesn't support TLSv1.2, so in order to support TLSv1.2 as communication protocol in VDSM we have to switch to Python standard SSL library. Because this change requires code changes and extensive testing, I'm targeting this to 4.2. But when patches are ready, we can discuss backports.
So at the end we have found that setting ssl_version to 'sslv23' in m2crypto allows support for TLSv12 (which is very confusing), so we don't need to switch to standard ssl library. According to this I'm targeting to 4.1.1 to allow us more time to test that change.
We tested ovirt-imageio, and it is already compliant, allowing TLS 1.1 and 1.2. See https://gerrit.ovirt.org/76654. According to https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls we should not allow TLS v1, but currently we do allow this protocol. We plan to improve this in 4.2. We did not test yet glance support. We access glance via curl using defaults, so I believe it will use the highest protocol supported by the server.
Exactly, nothing needs to be changed manually to allow using TLSv1.2, the only requirement is to have required versions engine and VDSM, which supports TLSv1.2. In short with latest 4.1.z engine or newer and all hosts being upgraded to latest 4.1.z, TLSv1.2 will be used. If not true, then highest available protocol will be used, here are details: 1. engine to external providers communication * engine 4.1.5 and newer - engine is able to negotiate up to TLSv1.2 (if external system supports TLSv1.2, engine will use it, if not, then engine will use older depending what external system supports) * engine 4.1.4 and older - engine is able to negotiate up to TLSv1 (even if external system supports TLSv1.2, engine will use TLSv1) 2. engine to VDSM communication * engine 4.1.5 and newer, VDSM 4.19.27 and newer - engine is able to negotiate TLSv1.2 and also VDSM supports TLSv1.2, so TLSv1.2 will be used * engine 4.1.5 and newer, VDSM 4.19.26 and older - engine is able to negotiate TLSv1.2 but VDSM supports only TLSv1, so TLSv1 will be used * engine 4.1.4 and older, VDSM 4.19.27 and newer - engine is able to negotiate TLSv1 and even when VDSM supports TLSv1.2, TLSv1 will be used * engine 4.1.4 and older, VDSM 4.19.26 and older - engine is able to negotiate TLSv1 and VDSM supports only TLSv1, so TLSv1 will be used 3. VDSM to VDSM communication * on both sides is VDSM 4.19.27 and newer - TLSv1.2 is supported on both sides, so it will be used * if on any side is VDSM 4.19.26 and older - only TLSv1 is supported on one side, so TLSv1 will be used THE IMPORTANT PART IS: NO MANUAL CHANGE IN ANY CONFIG IS REQUIRED, EVERYTHING DEPENDS ONLY ON INSTALLED VERSIONS.
CORRECTION OF COMMENT 38: In short with latest 4.1.z engine or newer and all hosts being upgraded to latest 4.1.z, TLSv1.2 will be used. If not true, then highest available protocol will be used, here are details: 1. engine to external providers communication * engine 4.1.5 and newer - engine is able to negotiate up to TLSv1.2 (if external system supports TLSv1.2, engine will use it, if not, then engine will use older depending what external system supports) * engine 4.1.4 and older - engine is able to negotiate up to TLSv1 (even if external system supports TLSv1.2, engine will use TLSv1) 2. engine to VDSM communication * engine 4.1.5 and newer, VDSM 4.19.38 and newer (part of oVirt/RHV 4.1.8) - engine is able to negotiate TLSv1.2 and also VDSM supports TLSv1.2, so TLSv1.2 will be used * engine 4.1.5 and newer, VDSM newer than 4.19.27 but older than 4.19.38 - engine is able to negotiate TLSv1.2 and also VDSM supports TLSv1.2, but manual configuration is required, see [IMPORTANT NOTES] * engine 4.1.5 and newer, VDSM 4.19.26 and older - engine is able to negotiate TLSv1.2 but VDSM supports only TLSv1, so TLSv1 will be used * engine 4.1.4 and older, VDSM 4.19.27 and newer - engine is able to negotiate TLSv1 and even when VDSM supports TLSv1.2, TLSv1 will be used * engine 4.1.4 and older, VDSM 4.19.26 and older - engine is able to negotiate TLSv1 and VDSM supports only TLSv1, so TLSv1 will be used 3. VDSM to VDSM communication * on both sides is VDSM 4.19.38 and newer (part of oVirt/RHV 4.1.8) - TLSv1.2 is supported on both sides, so it will be used * on both sides is VDSM newer than 4.19.26 and older than 4.19.38 - TLSv1.2 is supported on both sides, but manual configuration is required see [IMPORTANT NOTES] * if on any side is VDSM 4.19.26 and older - only TLSv1 is supported on one side, so TLSv1 will be used IMPORTANT NOTES: * For oVirt/RHV 4.1.8 and newer no manual configuration is required and TLSv1.2 will be used by default * For oVirt/RHV 4.1.5, 4.1.6, 4.1.7 manual configuration of VDSM greater than 4.19.26 and lower than 4.19.38 has to be performed on all hosts: 1. Put host to Maintenance 2. Create custom configuration file /etc/vdsm/vdsm.conf.d/99-enable-tlsv12.conf with following content: [vars] ssl_protocol=sslv23 3. Restart vdsmd service 4. Activate the host
ok, vdsm-4.20.9-1.el7ev.x86_64/vdsm-4.17.43-1.el7ev.noarch / ovirt-engine-4.2.0-0.5.master.el7.noarch
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://access.redhat.com/errata/RHEA-2018:1488
BZ<2>Jira Resync