Bug 1577593 - Disable TLS versions < 1.2 for hosts with cluster level >= 4.1
Summary: Disable TLS versions < 1.2 for hosts with cluster level >= 4.1
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: Host-Deploy
Version: 4.2.0
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ovirt-4.2.4
: ---
Assignee: Ravi Nori
QA Contact: Jiri Belka
URL:
Whiteboard:
Depends On: 1584669
Blocks: 1577594
TreeView+ depends on / blocked
 
Reported: 2018-05-13 11:16 UTC by Dan Kenigsberg
Modified: 2018-06-26 08:37 UTC (History)
9 users (show)

Fixed In Version: ovirt-engine-4.2.4.2
Doc Type: Release Note
Doc Text:
This change disables TLSv1 and TLSv11 for communication between engine and hosts for clusters with cluster level >= 4.1. Following steps need to be performed to apply the change: 1. Newly added hosts - The change is applied automatically when host is added to engine to clusters with cluster level >= 4.1 - When adding new host to cluster with cluster level 3.6 or 4.0 the change is not applied and the host supports TLSv1, TLSv11 and TLSv12 protocols 2. Existing hosts - to apply the change to existing host in cluster level 4.1 or 4.2 please follow steps described in [How to apply change] section 3. Moving hosts between clusters - when host is moved to 4.1 or 4.2 cluster the change is not applied automatically. To apply please follow steps described in [How to apply change] section How to apply change To disable older TLS versions for a host in cluster with cluster levels >= 4.1 following steps need to be applied: 1. Move host to Maintenance using option Maintenance in Management menu inside Hosts view 2. Reinstall the host using option Reinstall in Installation menu inside Hosts view 3. Activate the host after successful reinstallation using Activate option in Management menu inside Hosts view
Clone Of:
Environment:
Last Closed: 2018-06-26 08:37:20 UTC
oVirt Team: Infra
rule-engine: ovirt-4.2+
lsvaty: testing_ack+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1451297 0 unspecified CLOSED [RFE] Drop TLSv1 and TLSv1.1 encryption protocols support 2021-02-22 00:41:40 UTC
oVirt gerrit 91395 0 master ABANDONED Disable TLS versions < 1.2 for hosts with cluster level>=4.1 2020-11-10 18:11:42 UTC
oVirt gerrit 91445 0 master MERGED engine : Disable TLS versions < 1.2 for hosts with cluster level>=4.1 2020-11-10 18:11:42 UTC
oVirt gerrit 91606 0 ovirt-engine-4.2 MERGED engine : Disable TLS versions < 1.2 for hosts with cluster level>=4.1 2020-11-10 18:11:41 UTC
oVirt gerrit 91742 0 master MERGED revert: engine: Disable TLS versions < 1.2 for hosts with cluster level >= 4.1 2020-11-10 18:11:42 UTC
oVirt gerrit 91745 0 ovirt-engine-4.2 MERGED revert: engine: Disable TLS versions < 1.2 for hosts with cluster level >= 4.1 2020-11-10 18:11:42 UTC
oVirt gerrit 91809 0 master MERGED engine : Disable TLS versions < 1.2 for hosts with cluster level >= 4.1 2020-11-10 18:11:42 UTC
oVirt gerrit 91974 0 ovirt-engine-4.2 MERGED engine : Disable TLS versions < 1.2 for hosts with cluster level >= 4.1 2020-11-10 18:11:42 UTC

Internal Links: 1451297

Description Dan Kenigsberg 2018-05-13 11:16:49 UTC
Both Engine and Vdsm support new and improved TLS protocols as of clusterLevel 4.0.

When adding a host to a cluster >= 4.0, Engine should set

  ssl_excludes=OP_NO_TLSv1,OP_NO_TLSv1_1

in vdsm, to disable these outdated protocols.


Ondra Machacek suggested that the patch should go into https://github.com/oVirt/ovirt-engine/tree/master/packaging/playbooks/roles/ovirt-host-deploy and take an action based on host_deploy_cluster_version.

Comment 1 Jiri Belka 2018-05-14 07:29:52 UTC
(In reply to Dan Kenigsberg from comment #0)
> Both Engine and Vdsm support new and improved TLS protocols as of
> clusterLevel 4.0.
> 
> When adding a host to a cluster >= 4.0, Engine should set
> 
>   ssl_excludes=OP_NO_TLSv1,OP_NO_TLSv1_1
> 
> in vdsm, to disable these outdated protocols.
> 
> 
> Ondra Machacek suggested that the patch should go into
> https://github.com/oVirt/ovirt-engine/tree/master/packaging/playbooks/roles/
> ovirt-host-deploy and take an action based on host_deploy_cluster_version.

I suppose this won't be merged in any way to mess with env < 4.1.1.3, right? Because if so it would break those envs, as VDSMProtocol = TLSv1.2 seems to be first introduced only in 4.1.1.3 and lower env 4.0/4.1 versions already have cluster == 4.0.

Comment 2 Michal Skrivanek 2018-05-14 07:54:19 UTC
(In reply to Dan Kenigsberg from comment #0)
> When adding a host to a cluster >= 4.0, Engine should set

host is not being "deployed" to a cluster. Why do you need to differentiate anyway? When exactly do you have to not disable it?

Comment 3 Sandro Bonazzola 2018-05-14 11:29:46 UTC
Moving to Martin being this tracked as infra bug.

Comment 4 Martin Perina 2018-05-14 13:34:51 UTC
TLS version available in VDSM is not bound to cluster level, but to VDSM version. From oVirt 4.1.8 (vdsm 4.19.38 BZ1513886) VDSM supports TLSv12, but that host can be part of any cluster.

So I suggest to create Ansible role which:

1. Will check VDSM version on all hosts in a cluster
2. If version is always >= 4.19.38, then disable TLSv1 and TLSv11 using
    2.a Put host to maintenance
    2.b Create /etc/vdsm/vdsm.conf.d/99-restrict-tls.conf containing relevant options
    2.c Restart VDSM
    2.d Activate host

This flow should be performed with one host at a time similar to our cluster-upgrade role.

Comment 5 Dan Kenigsberg 2018-05-14 15:02:35 UTC
(In reply to Michal Skrivanek from comment #2)
> (In reply to Dan Kenigsberg from comment #0)
> > When adding a host to a cluster >= 4.0, Engine should set
> 
> host is not being "deployed" to a cluster. Why do you need to differentiate
> anyway? When exactly do you have to not disable it?

I thought that setting ssl_excludes=OP_NO_TLSv1,OP_NO_TLSv1_1 might cause a problem with older vdsm that may exist in a 3.6 cluster, but you may be true and we can set it to all newly-installed hosts. This config would be ignored by old vdsm if set on them, and would not harm their communication with hosts that do have vdsm>=4.19. (But this should be verified by QE)

(In reply to Martin Perina from comment #4)
> TLS version available in VDSM is not bound to cluster level, but to VDSM
> version. From oVirt 4.1.8 (vdsm 4.19.38 BZ1513886) VDSM supports TLSv12, but
> that host can be part of any cluster.
> 
> So I suggest to create Ansible role which:
> 
> 1. Will check VDSM version on all hosts in a cluster
> 2. If version is always >= 4.19.38, then disable TLSv1 and TLSv11 using
>     2.a Put host to maintenance
>     2.b Create /etc/vdsm/vdsm.conf.d/99-restrict-tls.conf containing
> relevant options
>     2.c Restart VDSM
>     2.d Activate host
> 
> This flow should be performed with one host at a time similar to our
> cluster-upgrade role.

An upgrade Ansible role is cool to have, but I think it belongs to ANOTHER bz. In this bug I'm referring to clean installation of a new host, not an upgrade of an existing system.

When ovirt-engine-4.2 adds a new host, it should set
ssl_excludes=OP_NO_TLSv1,OP_NO_TLSv1_1 on it.

Comment 6 Dan Kenigsberg 2018-05-17 15:18:55 UTC
Please note that I was not aware of bug 1451297 commit 17 when I filed this bug; yet it show this bug's urgency.

Comment 7 Martin Perina 2018-05-18 14:48:44 UTC
So, right now all VDSM configuration and service status changes are performed in classic host deploy and not in new ansible host-deploy. So to be able to provide easy backport to 4.2.z we need to perform those changes in classic host-deploy, which means that for all host installation or re-installation we will create /etc/vdsm/vdsm.conf.d/10-tls-setup.conf file with following content:

ssl_excludes=OP_NO_TLSv1,OP_NO_TLSv1_1

Comment 8 Martin Perina 2018-05-18 14:56:51 UTC
(In reply to Martin Perina from comment #7)
> So, right now all VDSM configuration and service status changes are
> performed in classic host deploy and not in new ansible host-deploy. So to
> be able to provide easy backport to 4.2.z we need to perform those changes
> in classic host-deploy, which means that for all host installation or
> re-installation we will create /etc/vdsm/vdsm.conf.d/10-tls-setup.conf file
> with following content:
> 
> ssl_excludes=OP_NO_TLSv1,OP_NO_TLSv1_1

Correction, we can do above only from cluster levels >= 4.1, because 3.6 and 4.0 hosts still may need TLSv1 to function properly

Comment 9 Marina Kalinin 2018-05-29 21:42:04 UTC
(In reply to Dan Kenigsberg from comment #6)
> Please note that I was not aware of bug 1451297 commit 17 when I filed this
> bug; yet it show this bug's urgency.

So, aren't the two basically the same and we should duplicate one of them?

Comment 10 Martin Perina 2018-05-30 12:04:37 UTC
(In reply to Marina from comment #9)
> (In reply to Dan Kenigsberg from comment #6)
> > Please note that I was not aware of bug 1451297 commit 17 when I filed this
> > bug; yet it show this bug's urgency.
> 
> So, aren't the two basically the same and we should duplicate one of them?

This one is newer and here engine just configures VDSM to disable older TLS versions.

BZ1451297 is older, we wanted completely removed older TLS versions (remove even options which could allow TLSv1 and TLSv11), which could be much easier and more consistent when you take a look at supported engine versions and host versions compatibility matrix.

Comment 11 Jiri Belka 2018-06-11 14:21:39 UTC
ok, vdsm-4.20.30-1.el7ev.x86_64

ovirt-engine-4.2.4.2-0.1.el7_3.noarch
ovirt-host-deploy-1.7.4-1.el7ev.noarch

install, host-deploy:

under 4.2/4.1 cluster:

# cat /etc/vdsm/vdsm.conf
[vars]
ssl_excludes = OP_NO_TLSv1,OP_NO_TLSv1_1
ssl = true
ssl_ciphers = HIGH

[addresses]
management_port = 54321

under 3.6/4.0 cluster:

# rpm -q vdsm
vdsm-4.20.30-1.el7ev.x86_64
# cat /etc/vdsm/vdsm.conf
[vars]
ssl = true

[addresses]
management_port = 54321

Comment 12 Jiri Belka 2018-06-11 14:26:24 UTC
correction, under 4.1 it was:

# cat /etc/vdsm/vdsm.conf
[vars]
ssl_excludes = OP_NO_TLSv1,OP_NO_TLSv1_1
ssl = true

[addresses]
management_port = 54321

because 4.2 adds ssl_ciphers https://bugzilla.redhat.com/show_bug.cgi?id=1582527

Comment 13 Sandro Bonazzola 2018-06-26 08:37:20 UTC
This bugzilla is included in oVirt 4.2.4 release, published on June 26th 2018.

Since the problem described in this bug report should be
resolved in oVirt 4.2.4 release, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.


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