Bug 1412552 - [RFE] Add TLSv1.2 support tor VDSM communication service
Summary: [RFE] Add TLSv1.2 support tor VDSM communication service
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: vdsm
Classification: oVirt
Component: Bindings-API
Version: 4.20.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ovirt-4.1.5
: 4.19.27
Assignee: Piotr Kliczewski
QA Contact: Jiri Belka
URL:
Whiteboard:
Depends On: 1473295 1473344
Blocks: RHV_TLS_1_2_SUPPORT 1454827
TreeView+ depends on / blocked
 
Reported: 2017-01-12 09:40 UTC by Martin Perina
Modified: 2019-04-28 13:14 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
VDSM now supports TLSv1.1 and TLSv1.2, enabling all clients to leverage these new encryption protocols, depending on their capabilities.
Clone Of:
Environment:
Last Closed: 2017-08-23 08:01:09 UTC
oVirt Team: Infra
rule-engine: ovirt-4.1+
rule-engine: exception+
gklein: testing_plan_complete-
mgoldboi: planning_ack+
mperina: devel_ack+
pstehlik: testing_ack+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 70015 0 master MERGED ssl: change protocol to tlsv1.2 2017-02-02 15:33:22 UTC
oVirt gerrit 72284 0 master MERGED ssl: enable tlsv1.2 support 2017-06-21 10:29:33 UTC
oVirt gerrit 72306 0 None None None 2017-03-14 10:33:28 UTC
oVirt gerrit 78028 0 master MERGED ssl: disable sslv3 on centos7 2017-06-21 10:29:30 UTC
oVirt gerrit 78665 0 ovirt-4.1 MERGED ssl: enable tlsv1.2 support 2017-07-04 07:50:51 UTC
oVirt gerrit 78666 0 ovirt-4.1 MERGED ssl: disable sslv3 on centos7 2017-07-04 07:59:16 UTC

Description Martin Perina 2017-01-12 09:40:52 UTC
Description of problem:

Underlying m2crypto library doesn't support TLSv1.2, so we need to switch to Python standard ssl library in order to provide TLSv1.2 support in VDSM.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Piotr Kliczewski 2017-01-12 10:45:49 UTC
The latest findings show that we can use tlsv1.2 using m2crypto when setting sslv23 as protocol.

Comment 2 Martin Perina 2017-01-13 06:11:21 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 3 Martin Perina 2017-02-13 13:37:20 UTC
Retargeting to 4.2, once finished we will discuss backport to 4.1.z

Comment 7 rhev-integ 2017-07-07 12:24:03 UTC
INFO: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason:

[Tag 'v4.19.21' doesn't contain patch 'https://gerrit.ovirt.org/78666']
gitweb: https://gerrit.ovirt.org/gitweb?p=vdsm.git;a=shortlog;h=refs/tags/v4.19.21

For more info please contact: infra@ovirt.org

Comment 8 Eyal Edri 2017-07-10 12:34:31 UTC
It looks like the patch is in the v4.19.21 tag and there seems to be a problem with the logic of the bot, moving to ON_QA while we'll investigate why it didn't move automatically.

Comment 9 Jiri Belka 2017-07-20 14:56:04 UTC
Putting back to assigned as only part of the feature implementation works, see BZ1473295, it does not work for 'ssl_implementation = ssl'.

Comment 10 Red Hat Bugzilla Rules Engine 2017-07-20 14:56:10 UTC
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.

Comment 11 Martin Perina 2017-07-23 21:40:10 UTC
Retargeting to 4.1.5 and moving to POST because of dependent bugs BZ1473295 and BZ1473344

Comment 12 Martin Perina 2017-07-23 21:53:42 UTC
Correcting the Doc Text, because m2crypto support has been only removed from master, but not from 4.1.z

Comment 13 Jiri Belka 2017-08-11 13:27:40 UTC
last thing to solve seems to be ssl_exclude feature which got probably a typo https://bugzilla.redhat.com/show_bug.cgi?id=1473344#c7

otherwise it works ok, tested with 4.1/4.1 and 3.6 hosts.

vdsm-4.19.27-1.el7ev.x86_64 / vdsm-4.17.43-1.el7ev.noarch

4.1 vdsm (default/m2c) -> engine => TLSv1
4.1 vdsm (default/ssl) -> engine => TLSv1

4.1 vdsm (sslv23/m2c) -> engine => TLSv1.2
 + ssl_excludes = OP_NO_TLSv1_1 => TLSv1.2 (https://bugzilla.redhat.com/show_bug.cgi?id=1473344#c7)
 + ssl_excludes = OP_NO_TLSv1_2 => TLSv1.1
 + ssl_excludes = OP_NO_TLSv1 => TLSv1.2
 + ssl_excludes = OP_NO_TLSv1,OP_NO_TLSv1_2 => TLSv1.1
 + ssl_excludes = OP_NO_TLSv1_1,OP_NO_TLSv1_2 => TLSv1.1 (https://bugzilla.redhat.com/show_bug.cgi?id=1473344#c7)

4.1 vdsm (sslv23/ssl) -> engine => TLSv1.2
 + ssl_excludes = OP_NO_TLSv1_1 => TLSv1.2 (https://bugzilla.redhat.com/show_bug.cgi?id=1473344#c7)
 + ssl_excludes = OP_NO_TLSv1_2 => TLSv1.1
 + ssl_excludes = OP_NO_TLSv1 => TLSv1.2
 + ssl_excludes = OP_NO_TLSv1,OP_NO_TLSv1_2 => TLSv1.1
 + ssl_excludes = OP_NO_TLSv1_1,OP_NO_TLSv1_2 => TLSv1.1 (https://bugzilla.redhat.com/show_bug.cgi?id=1473344#c7)

4.1 vdsm (default/m2c) <-> 3.6/4.1 vdsm (default/m2c) => TLSv1
4.1 vdsm (default/m2c) <-> 3.6/4.1 vdsm (default/ssl) => TLSv1
4.1 vdsm (default/m2c) <-> 3.6/4.1 vdsm (sslv23/m2c) => TLSv1
4.1 vdsm (default/m2c) <-> 3.6/4.1 vdsm (sslv23/ssl) => TLSv1

4.1 vdsm (default/ssl) <-> 3.6/4.1 vdsm (default/m2c) => TLSv1
4.1 vdsm (default/ssl) <-> 3.6/4.1 vdsm (default/ssl) => TLSv1
4.1 vdsm (default/ssl) <-> 3.6/4.1 vdsm (sslv23/m2c) => TLSv1
4.1 vdsm (default/ssl) <-> 3.6/4.1 vdsm (sslv23/ssl) => TLSv1

4.1 vdsm (sslv23/m2c) <-> 3.6/4.1 vdsm (sslv23/m2c) => TLSv1.2
4.1 vdsm (sslv23/m2c) <-> 3.6/4.1 vdsm (sslv23/ssl) => TLSv1.2
4.1 vdsm (sslv23/m2c) <-> 3.6/4.1 vdsm (default/m2c) => TLSv1
4.1 vdsm (sslv23/m2c) <-> 3.6/4.1 vdsm (default/ssl) => TLSv1

4.1 vdsm (sslv23/ssl) <-> 3.6/4.1 vdsm (default/ssl) => TLSv1
4.1 vdsm (sslv23/ssl) <-> 3.6/4.1 vdsm (default/m2c) => TLSv1
4.1 vdsm (sslv23/ssl) <-> 3.6/4.1 vdsm (sslv23/ssl) => TLSv1.2
4.1 vdsm (sslv23/ssl) <-> 3.6/4.1 vdsm (sslv23/m2c) => TLSv1.2

Comment 14 Jiri Belka 2017-08-16 09:40:10 UTC
ok, vdsm-4.19.28-1.el7ev.x86_64

Comment 15 Donald Berry 2017-10-24 18:26:41 UTC
Hi Jiri, can you elaborate on comment 13?

---
it works ok, tested with 4.1/4.1 and 3.6 hosts.
vdsm-4.19.27-1.el7ev.x86_64 / vdsm-4.17.43-1.el7ev.noarch
4.1 vdsm (default/m2c) -> engine => TLSv1
...
4.1 vdsm (default/m2c) <-> 3.6/4.1 vdsm (default/m2c) => TLSv1
...
---

- what version of vdsm did you test? (you mention two versions, vdsm-4.19.27-1.el7ev.x86_64 / vdsm-4.17.43-1.el7ev.noarch)
- how did you test it?
- what does "tested with 4.1/4.1 and 3.6 hosts" mean?
- can you explain how to configure vdsm to support TLS 1.1 or 1.2.  Are you referring to ssl_version (default, sslv23) and ssl_implementation (ssl, m2c) in /etc/vdsm/vdsm.conf in those comments?
- does "4.1 vdsm (default/m2c) <-> 3.6/4.1 vdsm (default/m2c) => TLSv1" mean you are testing between two hosts?
- what engine versions support TLS 1.1/1.2?
- are any config. settings needed on the engine?

Thanks.

Don

Comment 16 Martin Perina 2017-10-25 09:15:25 UTC
(In reply to Donald Berry from comment #15)
> Hi Jiri, can you elaborate on comment 13?
> 
> ---
> it works ok, tested with 4.1/4.1 and 3.6 hosts.
> vdsm-4.19.27-1.el7ev.x86_64 / vdsm-4.17.43-1.el7ev.noarch
> 4.1 vdsm (default/m2c) -> engine => TLSv1
> ...
> 4.1 vdsm (default/m2c) <-> 3.6/4.1 vdsm (default/m2c) => TLSv1
> ...
> ---
> 
> - what version of vdsm did you test? (you mention two versions,
> vdsm-4.19.27-1.el7ev.x86_64 / vdsm-4.17.43-1.el7ev.noarch)
> - how did you test it?
> - what does "tested with 4.1/4.1 and 3.6 hosts" mean?
> - can you explain how to configure vdsm to support TLS 1.1 or 1.2.  Are you
> referring to ssl_version (default, sslv23) and ssl_implementation (ssl, m2c)
> in /etc/vdsm/vdsm.conf in those comments?
> - does "4.1 vdsm (default/m2c) <-> 3.6/4.1 vdsm (default/m2c) => TLSv1" mean
> you are testing between two hosts?
> - what engine versions support TLS 1.1/1.2?
> - are any config. settings needed on the engine?
> 
> Thanks.
> 
> Don

Donald, please take a look at [1], no manual configuration is not required and AFAIK also not supported.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1408847#c38


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