Bug 1412552

Summary:	[RFE] Add TLSv1.2 support tor VDSM communication service
Product:	[oVirt] vdsm	Reporter:	Martin Perina <mperina>
Component:	Bindings-API	Assignee:	Piotr Kliczewski <pkliczew>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Jiri Belka <jbelka>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	4.20.0	CC:	bugs, dberry, eedri, mgoldboi, pkliczew
Target Milestone:	ovirt-4.1.5	Keywords:	FutureFeature
Target Release:	4.19.27	Flags:	rule-engine: ovirt-4.1+ rule-engine: exception+ gklein: testing_plan_complete- mgoldboi: planning_ack+ mperina: devel_ack+ pstehlik: testing_ack+
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
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.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-08-23 08:01:09 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Infra	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1473295, 1473344
Bug Blocks:	1408847, 1454827

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

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