Bug 1514004 - [downstream clone - 4.3.0] [RFE] Drop TLSv1 and TLSv1.1 encryption protocols support
Summary: [downstream clone - 4.3.0] [RFE] Drop TLSv1 and TLSv1.1 encryption protocols ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: vdsm
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ovirt-4.3.0
: ---
Assignee: Martin Perina
QA Contact: Petr Matyáš
Rolfe Dlugy-Hegwer
URL:
Whiteboard:
Depends On: vdsm_tls1_2
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-11-16 13:24 UTC by rhev-integ
Modified: 2021-09-09 12:50 UTC (History)
13 users (show)

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.
Clone Of: vdsm_tls1_2
Environment:
Last Closed: 2019-05-08 12:35:59 UTC
oVirt Team: Infra
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHV-43208 0 None None None 2021-08-30 12:10:52 UTC
Red Hat Knowledge Base (Solution) 2335221 0 None None None 2017-11-16 13:25:57 UTC
Red Hat Knowledge Base (Solution) 2845461 0 None None None 2017-11-16 13:25:57 UTC
Red Hat Product Errata RHBA-2019:1077 0 None None None 2019-05-08 12:36:29 UTC
oVirt gerrit 96647 0 master MERGED ssl: Forcefully disable TLSv1 and TLSv1.1 protocols 2020-10-14 19:14:56 UTC

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


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