Red Hat Bugzilla – Bug 1454827
[downstream clone - 4.1.5] [RFE][Tracker] Requesting testing of support for TLSv1.2
Last modified: 2017-12-05 13:20:17 EST
+++ This bug is a downstream clone. The original bug is: +++ +++ bug 1408847 +++ ====================================================================== 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: (Originally by Gordon Watson)
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 (Originally by Donald Berry)
See also: https://bugzilla.redhat.com/show_bug.cgi?id=1387996#c7 (Originally by Marina Kalinin)
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 (Originally by Piotr Kliczewski)
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. (Originally by Martin Perina)
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. (Originally by Martin Perina)
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. (Originally by Nir Soffer)
Moving to modified, as bug 1412552 is now modified as well.
INFO: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason: [No relevant external trackers attached] For more info please contact: rhv-devops@redhat.com
Moving to 4.1.5 because of dependent bugs
ok, vdsm-4.19.28-1.el7ev.x86_64
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-2017:2509