Bug 1419540
| Summary: | [downstream clone - 4.0.7] Allow negotiation of highest available TLS version for engine <-> VDSM communication | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Virtualization Manager | Reporter: | rhev-integ |
| Component: | ovirt-engine | Assignee: | Ondra Machacek <omachace> |
| Status: | CLOSED ERRATA | QA Contact: | Jiri Belka <jbelka> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | unspecified | CC: | bugs, eheftman, gklein, lsurette, mgoldboi, mperina, pstehlik, rbalakri, Rhev-m-bugs, srevivo, trichard, ykaul |
| Target Milestone: | ovirt-4.0.7 | Keywords: | ZStream |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| 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.
|
Story Points: | --- |
| Clone Of: | 1412547 | Environment: | |
| Last Closed: | 2017-03-16 15:33:05 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: | 1412547 | ||
| Bug Blocks: | |||
|
Description
rhev-integ
2017-02-06 13:13:57 UTC
Retargeting to 4.1.1 to allow more extensive testing of the feature (Originally by Martin Perina) 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
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 |