Bug 1514004

Summary:	[downstream clone - 4.3.0] [RFE] Drop TLSv1 and TLSv1.1 encryption protocols support
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	rhev-integ
Component:	vdsm	Assignee:	Martin Perina <mperina>
Status:	CLOSED ERRATA	QA Contact:	Petr Matyáš <pmatyas>
Severity:	high	Docs Contact:	Rolfe Dlugy-Hegwer <rdlugyhe>
Priority:	unspecified
Version:	unspecified	CC:	bugs, danken, dberry, dfodor, jentrena, lsurette, lsvaty, mgoldboi, mkalinin, mperina, rdlugyhe, srevivo, ycui
Target Milestone:	ovirt-4.3.0	Keywords:	FutureFeature, ZStream
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	v4.30.6	Doc Type:	Release Note
Doc Text:	The TLSv1 and TLSv1.1 protocols are no longer secure. In the current release, they have been forcefully disabled in the VDSM configuration and cannot be enabled. Only TLSv1.2 and higher versions of the protocol are enabled. The exact version enabled depends on the underlying OpenSSL version.	Story Points:	---
Clone Of:	vdsm_tls1_2	Environment:
Last Closed:	2019-05-08 12:35:59 UTC	Type:	---
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:	1451297
Bug Blocks:

Description rhev-integ 2017-11-16 13:24:17 UTC

+++ This bug is an upstream to downstream clone. The original bug is: +++
+++   bug 1451297 +++
======================================================================

Description of problem:

In BZ1412552 we have added support for TLSv1.1 and TLSv1.2 communication protocols to VDSM (which already supported TLSv1). oVirt Engine 3.6 can communicate with VDSM only using TLSv1, but oVirt Engine 4.x already support TLSv1.2. So the plan is to drop support for already insecure TLSv1 [1] and TLSv1.1 and leave only most secure TLSv1.2 [2].


[1] https://blog.varonis.com/ssl-and-tls-1-0-no-longer-acceptable-for-pci-compliance/

[2] https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_1.2


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


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

(Originally by Martin Perina)

Comment 1 rhev-integ 2017-11-16 13:24:26 UTC

Moving to 4.3, because implementing this will break 3.6 compatibility, because both 3.6 engine and VDSM support only TLSv1

(Originally by Martin Perina)

Comment 8 rhev-integ 2017-11-16 13:25:04 UTC

TLSv1 and/or TLSv1.1 protocols used for engine <-> VDSM and VDSM <-> VDSM communication can be disabled by manual configuration on all hosts:

1. Put host into the maintenance

2. Create custom configuration file /etc/vdsm/vdsm.conf.d/99-disable-older-tls.conf with following content:

   ssl_excludes = OP_NO_TLSv1,OP_NO_TLSv1_1

3. Restart VDSM

4. Activate the host

When above steps are applied all hosts in RHV setup, then only TLSv1.2 will be used for engine <-> VDSM and VDSM <-> VDSM communication.

IMPORTANT: Above manual configuration change can be applied only to RHV 4.1.5 and newer versions, where all hosts are upgraded to VDSM 4.19.27 and newer (more info at [1]). If this condition is not true, all older hosts will become NonResponsive and VMs won't be able to migrat to/from those older hosts.

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

(Originally by Martin Perina)

Comment 9 rhev-integ 2017-11-16 13:25:11 UTC

Martin, how about the manager?
I believe we should add here also requirement on the engine to be 4.1.5 and up, right?

(Originally by Marina Kalinin)

Comment 10 rhev-integ 2017-11-16 13:25:18 UTC

(In reply to Marina from comment #8)
> Martin, how about the manager?
> I believe we should add here also requirement on the engine to be 4.1.5 and
> up, right?

The requirement is mentioned in comment 7:

> IMPORTANT: Above manual configuration change can be applied only to RHV
> 4.1.5 and newer versions, where all hosts are upgraded to VDSM 4.19.27 and
> newer (more info at [1]). If this condition is not true, all older hosts
> will become NonResponsive and VMs won't be able to migrat to/from those
> older hosts.
> 
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1408847#c38

(Originally by Martin Perina)

Comment 11 rhev-integ 2017-11-16 13:25:24 UTC

This comment fixes and overrides information from Comment 7:

TLSv1 and/or TLSv1.1 protocols used for engine <-> VDSM and VDSM <-> VDSM communication can be disabled by manual configuration on all hosts:

1. Put host into the maintenance

2. Create custom configuration file /etc/vdsm/vdsm.conf.d/99-disable-older-tls.conf with following content:

   [vars]
   ssl_excludes = OP_NO_TLSv1,OP_NO_TLSv1_1

3. Restart VDSM

4. Activate the host

When above steps are applied all hosts in RHV setup, then only TLSv1.2 will be used for engine <-> VDSM and VDSM <-> VDSM communication.

IMPORTANT: Above manual configuration change can be applied only to RHV 4.1.5 and newer versions, where engine is upgraded to 4.1.5 and newer and all hosts are upgraded to VDSM 4.19.27 and newer (more info at [1]). If this condition is not true, all older hosts will become NonResponsive and VMs won't be able to migrat to/from those older hosts.

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

(Originally by Martin Perina)

Comment 12 rhev-integ 2017-11-16 13:25:31 UTC

OK, so we have found an issue: from 4.1.5 the TLSv12 support is included, but it's disabled by default. To enable it following VDSM options need to be updated to:

  ssl_protocol=sslv23

In RHV 4.2 this is enabled by default, we will backport it to 4.1.8 (BZ1511962). So if you want to disable TLSv1/TLSv11, you need also to have this options set in  configuration file mentioned Comment 10.

(Originally by Martin Perina)

Comment 13 rhev-integ 2017-11-16 13:25:37 UTC

Hi Martin, will 4.2 have that var (ssl_protocol=sslv23) included in vdsm.conf, or do you mean it will not be required in 4.2?

I tested the config to enable v.1.2 and disable v1.0, it works:

[root@rhevh-25 ~]# rpm -q vdsm
vdsm-4.19.28-1.el7ev.x86_64

- by default, it does not use v.1.2

[root@rhevh-25 ~]# openssl s_client -connect localhost:54321 -CAfile /etc/pki/vdsm/certs/cacert.pem 2>&1 | grep -e Protocol -e Cipher
New, TLSv1/SSLv3, Cipher is AES256-SHA
    Protocol  : TLSv1
    Cipher    : AES256-SHA

- enable v.1.2

[root@rhevh-25 ~]# cp /etc/vdsm/vdsm.conf /etc/vdsm/vdsm.conf.0
[root@rhevh-25 ~]# vi /etc/vdsm/vdsm.conf
[root@rhevh-25 ~]# diff /etc/vdsm/vdsm.conf /etc/vdsm/vdsm.conf.0
3d2
< ssl_protocol = sslv23
[root@rhevh-25 ~]# systemctl restart vdsmd.service
[root@rhevh-25 ~]# openssl s_client -connect localhost:54321 -CAfile /etc/pki/vdsm/certs/cacert.pem 2>&1 | grep -e Protocol -e Cipher
New, TLSv1/SSLv3, Cipher is AES256-GCM-SHA384
    Protocol  : TLSv1.2
    Cipher    : AES256-GCM-SHA384

- it still supports v.1.0

[root@rhevh-25 ~]# openssl s_client -connect localhost:54321 -CAfile /etc/pki/vdsm/certs/cacert.pem 2>&1 -tls1 | grep -e Protocol -e Cipher
New, TLSv1/SSLv3, Cipher is AES256-SHA
    Protocol  : TLSv1
    Cipher    : AES256-SHA

- disable v.1.0/v.1.1

[root@rhevh-25 ~]# vi /etc/vdsm/vdsm.conf
[root@rhevh-25 ~]# diff /etc/vdsm/vdsm.conf /etc/vdsm/vdsm.conf.0
3,4d2
< ssl_protocol = sslv23
< ssl_excludes = OP_NO_TLSv1,OP_NO_TLSv1_1
[root@rhevh-25 ~]# systemctl restart vdsmd.service
[root@rhevh-25 ~]# openssl s_client -connect localhost:54321 -CAfile /etc/pki/vdsm/certs/cacert.pem 2>&1 -tls1 | grep -e Protocol -e Cipher
New, (NONE), Cipher is (NONE)
    Protocol  : TLSv1
    Cipher    : 0000

- it still supports v.1.2

[root@rhevh-25 ~]# openssl s_client -connect localhost:54321 -CAfile /etc/pki/vdsm/certs/cacert.pem 2>&1 | grep -e Protocol -e Cipher
New, TLSv1/SSLv3, Cipher is AES256-GCM-SHA384
    Protocol  : TLSv1.2
    Cipher    : AES256-GCM-SHA384

(Originally by Donald Berry)

Comment 14 rhev-integ 2017-11-16 13:25:44 UTC

(In reply to Donald Berry from comment #12)
> Hi Martin, will 4.2 have that var (ssl_protocol=sslv23) included in
> vdsm.conf, or do you mean it will not be required in 4.2?

vdsm.conf does not include default values, it only specifies values for options, which don't have default value, or overwrites default values specified in the VDSM code.

> 
> I tested the config to enable v.1.2 and disable v1.0, it works:
> 
> [root@rhevh-25 ~]# rpm -q vdsm
> vdsm-4.19.28-1.el7ev.x86_64
> 
> - by default, it does not use v.1.2
> 
> [root@rhevh-25 ~]# openssl s_client -connect localhost:54321 -CAfile
> /etc/pki/vdsm/certs/cacert.pem 2>&1 | grep -e Protocol -e Cipher
> New, TLSv1/SSLv3, Cipher is AES256-SHA
>     Protocol  : TLSv1
>     Cipher    : AES256-SHA

Right, will be fixed in 4.1.8 (BZ1511962)

> 
> - enable v.1.2
> 
> [root@rhevh-25 ~]# cp /etc/vdsm/vdsm.conf /etc/vdsm/vdsm.conf.0
> [root@rhevh-25 ~]# vi /etc/vdsm/vdsm.conf
> [root@rhevh-25 ~]# diff /etc/vdsm/vdsm.conf /etc/vdsm/vdsm.conf.0
> 3d2
> < ssl_protocol = sslv23

Please don't vdsm.conf directly, it's preferred to do user customizations via custom .conf file in vdsm.conf.d (see my example in Comment 10)

> [root@rhevh-25 ~]# systemctl restart vdsmd.service
> [root@rhevh-25 ~]# openssl s_client -connect localhost:54321 -CAfile
> /etc/pki/vdsm/certs/cacert.pem 2>&1 | grep -e Protocol -e Cipher
> New, TLSv1/SSLv3, Cipher is AES256-GCM-SHA384
>     Protocol  : TLSv1.2
>     Cipher    : AES256-GCM-SHA384
> 
> - it still supports v.1.0

Yes, TLSv1 is still supported, but most of clients negotiate highest available version, which is TLSv12

> 
> [root@rhevh-25 ~]# openssl s_client -connect localhost:54321 -CAfile
> /etc/pki/vdsm/certs/cacert.pem 2>&1 -tls1 | grep -e Protocol -e Cipher
> New, TLSv1/SSLv3, Cipher is AES256-SHA
>     Protocol  : TLSv1
>     Cipher    : AES256-SHA
> 
> - disable v.1.0/v.1.1
> 
> [root@rhevh-25 ~]# vi /etc/vdsm/vdsm.conf
> [root@rhevh-25 ~]# diff /etc/vdsm/vdsm.conf /etc/vdsm/vdsm.conf.0
> 3,4d2
> < ssl_protocol = sslv23
> < ssl_excludes = OP_NO_TLSv1,OP_NO_TLSv1_1

Same as above, please don't edit vdsm.conf directly

> [root@rhevh-25 ~]# systemctl restart vdsmd.service
> [root@rhevh-25 ~]# openssl s_client -connect localhost:54321 -CAfile
> /etc/pki/vdsm/certs/cacert.pem 2>&1 -tls1 | grep -e Protocol -e Cipher
> New, (NONE), Cipher is (NONE)
>     Protocol  : TLSv1
>     Cipher    : 0000
> 
> - it still supports v.1.2

It supports only TLSv12, everything else is disabled

> 
> [root@rhevh-25 ~]# openssl s_client -connect localhost:54321 -CAfile
> /etc/pki/vdsm/certs/cacert.pem 2>&1 | grep -e Protocol -e Cipher
> New, TLSv1/SSLv3, Cipher is AES256-GCM-SHA384
>     Protocol  : TLSv1.2
>     Cipher    : AES256-GCM-SHA384

(Originally by Martin Perina)

Comment 16 Petr Matyáš 2019-01-17 09:29:56 UTC

Verified on vdsm-4.30.4-1.el7ev.x86_64

'openssl s_client -connect localhost:54321 -tls1 -CAfile /etc/pki/vdsm/certs/cacert.pem' and with tls1_1 this returns errno 104 and reads no bytes

'openssl s_client -connect localhost:54321 -tls1_2 -CAfile /etc/pki/vdsm/certs/cacert.pem' works correctly, shows certificate and reads some bytes

Comment 18 errata-xmlrpc 2019-05-08 12:35:59 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/RHBA-2019:1077