Bug 1419540 - [downstream clone - 4.0.7] Allow negotiation of highest available TLS version for engine <-> VDSM communication
Summary: [downstream clone - 4.0.7] Allow negotiation of highest available TLS version...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ovirt-4.0.7
: ---
Assignee: Ondra Machacek
QA Contact: Jiri Belka
URL:
Whiteboard:
Depends On: 1412547
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-02-06 13:13 UTC by rhev-integ
Modified: 2017-03-16 15:33 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Previously, the Manager tried to negotiate the highest available version of TLS when connecting to VDSM. However, due to certain limitations the Manager tried to negotiate TLSv1.0 as the highest version. Now, the limitations have been removed and the Manager is able to negotiate TLSv1.1 and TLSv1.2 when they are available on VDSM. Removing these limitations also enables providing only newer TLS versions in future VDSM versions.
Clone Of: 1412547
Environment:
Last Closed: 2017-03-16 15:33:05 UTC
oVirt Team: Infra
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:0542 0 normal SHIPPED_LIVE Red Hat Virtualization Manager 4.0.7 2017-03-16 19:25:04 UTC
oVirt gerrit 70038 0 master MERGED vdsbroker: Update ssl protocol version 2017-02-06 13:14:14 UTC
oVirt gerrit 70559 0 ovirt-engine-4.1 MERGED vdsbroker: Update ssl protocol version 2017-02-06 13:14:14 UTC
oVirt gerrit 70918 0 master MERGED http: use protocol which is understood by http client 2017-02-06 13:14:14 UTC
oVirt gerrit 71722 0 None None None 2017-02-07 09:20:11 UTC

Description rhev-integ 2017-02-06 13:13:57 UTC
+++ This bug is an upstream to downstream clone. The original bug is: +++
+++   bug 1412547 +++
======================================================================

Description of problem:

At the moment we limit protocol negotiation to TLSv1.0, because issues with m2crypto in the past. We were not able to reproduce those issues in latest m2crypto on EL7, so we can remove this limit and allow engine to negotiate highest TLS version available on VDSM side.

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-02-06 13:14:05 UTC
Retargeting to 4.1.1 to allow more extensive testing of the feature

(Originally by Martin Perina)

Comment 4 Jiri Belka 2017-03-01 11:47:54 UTC
ok, ovirt-engine-4.0.7.1-0.1.el7ev.noarch

originally on 4.0 - rhevm-4.0.6.3-0.1.el7ev.noarch

engine=# select * from vdc_options where option_name ilike '%vdsmsslprotocol%';
 option_id |   option_name   | option_value | version 
-----------+-----------------+--------------+---------
       255 | VdsmSSLProtocol | TLSv1        | general
(1 row)

after upgrade to version used for verification

engine=# select * from vdc_options where option_name ilike '%vdsmsslprotocol%';
 option_id |   option_name   | option_value | version 
-----------+-----------------+--------------+---------
       255 | VdsmSSLProtocol | TLSv1.2      | general
(1 row)

engine=# \q
-bash-4.2$ rpm -q rhevm
rhevm-4.0.7.1-0.1.el7ev.noarch

tests, checked with wireshark[1]:

1. VdsmSSLProtocol = TLSv1.2 vs ssl_protocol = tlsv1
   > client tls 1.2, agreed tls 1.0
2. VdsmSSLProtocol = TLSv1.1 vs ssl_protocol = tlsv1
   > client tls 1.1, agreed tls 1.0
3. VdsmSSLProtocol = TLSv1.1 vs ssl_protocol = tlsv1
   > client tls 1.0, agreed tls 1.0
4. VdsmSSLProtocol = TLSv1.2 vs ssl_protocol = sslv23
   > client tls 1.2, agreed tls 1.2
4. VdsmSSLProtocol = TLSv1.1 vs ssl_protocol = sslv23
   > client tls 1.1, agreed tls 1.1
4. VdsmSSLProtocol = SSLv3 vs ssl_protocol = sslv23
   > client tls 1.1, agreed tls 1.1

[1] http://security.stackexchange.com/questions/100029/how-do-we-determine-the-ssl-tls-version-of-an-http-request

Comment 6 errata-xmlrpc 2017-03-16 15:33:05 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://rhn.redhat.com/errata/RHBA-2017-0542.html


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