Bug 1408847 (RHV_TLS_1_2_SUPPORT) - [RFE][Tracker] Requesting testing of support for TLSv1.2
Summary: [RFE][Tracker] Requesting testing of support for TLSv1.2
Status: CLOSED ERRATA
Alias: RHV_TLS_1_2_SUPPORT
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 4.0.6
Hardware: All
OS: Linux
high
high
Target Milestone: ovirt-4.2.0
: ---
Assignee: Martin Perina
QA Contact: Jiri Belka
URL:
Whiteboard:
Keywords: FutureFeature, Tracking, ZStream
Depends On: 1387996 1388456 1412547 1412550 1412552 1421204
Blocks: 1454827
TreeView+ depends on / blocked
 
Reported: 2016-12-27 17:11 UTC by Gordon Watson
Modified: 2019-05-16 13:18 UTC (History)
16 users (show)

(edit)
Red Hat Virtualization now supports TLSv1.2.
Clone Of:
: 1454827 (view as bug list)
(edit)
Last Closed: 2018-05-15 17:38:43 UTC
jbelka: testing_plan_complete+


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2018:1488 None None None 2018-05-15 17:40 UTC
Red Hat Bugzilla 1379932 None CLOSED [CodeChange] drop usage of M2Crypto from engine-setup 2019-03-28 13:41 UTC
Red Hat Knowledge Base (Solution) 2845461 None None None 2017-11-01 17:23 UTC

Internal Trackers: 1379932

Description Gordon Watson 2016-12-27 17:11:34 UTC
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:

Comment 3 Donald Berry 2016-12-28 14:29:58 UTC
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

Comment 5 Marina Kalinin 2016-12-28 21:42:55 UTC
See also:
https://bugzilla.redhat.com/show_bug.cgi?id=1387996#c7

Comment 15 Piotr Kliczewski 2017-01-11 14:55:29 UTC
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

Comment 16 Martin Perina 2017-01-12 09:45:21 UTC
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.

Comment 17 Martin Perina 2017-01-13 06:06:57 UTC
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.

Comment 23 Nir Soffer 2017-05-10 19:54:48 UTC
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.

Comment 38 Martin Perina 2017-10-25 09:10:44 UTC
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.

Comment 44 Martin Perina 2017-11-16 11:34:26 UTC
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

Comment 45 Jiri Belka 2017-12-11 14:01:41 UTC
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

Comment 49 errata-xmlrpc 2018-05-15 17:38:43 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://access.redhat.com/errata/RHEA-2018:1488

Comment 50 Franta Kust 2019-05-16 13:07:54 UTC
BZ<2>Jira Resync


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