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:
The latest findings show that we can use tlsv1.2 using m2crypto when setting sslv23 as protocol.
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.
Retargeting to 4.2, once finished we will discuss backport to 4.1.z
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
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.
Putting back to assigned as only part of the feature implementation works, see BZ1473295, it does not work for 'ssl_implementation = ssl'.
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.
Retargeting to 4.1.5 and moving to POST because of dependent bugs BZ1473295 and BZ1473344
Correcting the Doc Text, because m2crypto support has been only removed from master, but not from 4.1.z
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
ok, vdsm-4.19.28-1.el7ev.x86_64
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
(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