RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1333415 - libvirtd allows SSLv3 connections and poor ciphers
Summary: libvirtd allows SSLv3 connections and poor ciphers
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt
Version: 6.8
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Ján Tomko
QA Contact: yafu
Yehuda Zimmerman
Depends On: 1333404
Blocks: 1269194 1339222 1343211 1359965 1364808
TreeView+ depends on / blocked
Reported: 2016-05-05 12:52 UTC by Martin Poole
Modified: 2021-09-09 11:50 UTC (History)
11 users (show)

Fixed In Version: libvirt-0.10.2-61.el6
Doc Type: Enhancement
Doc Text:
Configuration options can be used to exclude weak ciphers Previously, _libvirt_ depended on the hard-coded cipher defaults in *GnuTLS*. This made it possible to use weak ciphers. With this update, configuration options to exclude weak ciphers have been added to the `libvirtd.conf` and `libvirt.conf` files. In addition, *TLS* priority support was added to _libvirt_ URIs. As a a result, the list of used ciphers can be customized to exclude weak ciphers.
Clone Of: 1333404
Last Closed: 2017-03-21 10:39:08 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:0682 0 normal SHIPPED_LIVE libvirt bug fix and enhancement update 2017-03-21 12:37:01 UTC

Description Martin Poole 2016-05-05 12:52:54 UTC
+++ This bug was initially created as a clone of Bug #1333404 +++

Description of problem:

because there is no mechanism to provide a gnutls cipher string it defaults to the library hard-coded selection which allows SSLv3 and numerous weak ciphers.

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


How reproducible:


Steps to Reproduce:
1. Enable TLS and scan

Actual results:

  Supported Server Cipher(s):
Accepted  SSLv3    256 bits  DHE-RSA-AES256-SHA
Accepted  SSLv3    256 bits  DHE-RSA-CAMELLIA256-SHA
Accepted  SSLv3    256 bits  AES256-SHA
Accepted  SSLv3    256 bits  CAMELLIA256-SHA
Accepted  SSLv3    128 bits  DHE-RSA-AES128-SHA
Accepted  SSLv3    128 bits  DHE-RSA-CAMELLIA128-SHA
Accepted  SSLv3    128 bits  EDH-RSA-DES-CBC3-SHA
Accepted  SSLv3    128 bits  AES128-SHA
Accepted  SSLv3    128 bits  CAMELLIA128-SHA
Accepted  SSLv3    128 bits  DES-CBC3-SHA
Accepted  SSLv3    128 bits  RC4-SHA
Accepted  SSLv3    128 bits  RC4-MD5
Accepted  TLSv1.0  256 bits  ECDHE-RSA-AES256-SHA
Accepted  TLSv1.0  256 bits  DHE-RSA-AES256-SHA
Accepted  TLSv1.0  256 bits  DHE-RSA-CAMELLIA256-SHA
Accepted  TLSv1.0  256 bits  AES256-SHA
Accepted  TLSv1.0  256 bits  CAMELLIA256-SHA
Accepted  TLSv1.0  128 bits  ECDHE-RSA-AES128-SHA
Accepted  TLSv1.0  128 bits  DHE-RSA-AES128-SHA
Accepted  TLSv1.0  128 bits  ECDHE-RSA-DES-CBC3-SHA
Accepted  TLSv1.0  128 bits  DHE-RSA-CAMELLIA128-SHA
Accepted  TLSv1.0  128 bits  EDH-RSA-DES-CBC3-SHA
Accepted  TLSv1.0  128 bits  AES128-SHA
Accepted  TLSv1.0  128 bits  CAMELLIA128-SHA
Accepted  TLSv1.0  128 bits  DES-CBC3-SHA
Accepted  TLSv1.0  128 bits  ECDHE-RSA-RC4-SHA
Accepted  TLSv1.0  128 bits  RC4-SHA
Accepted  TLSv1.0  128 bits  RC4-MD5
Accepted  TLSv1.1  256 bits  ECDHE-RSA-AES256-SHA
Accepted  TLSv1.1  256 bits  DHE-RSA-AES256-SHA
Accepted  TLSv1.1  256 bits  DHE-RSA-CAMELLIA256-SHA
Accepted  TLSv1.1  256 bits  AES256-SHA
Accepted  TLSv1.1  256 bits  CAMELLIA256-SHA
Accepted  TLSv1.1  128 bits  ECDHE-RSA-AES128-SHA
Accepted  TLSv1.1  128 bits  DHE-RSA-AES128-SHA
Accepted  TLSv1.1  128 bits  ECDHE-RSA-DES-CBC3-SHA
Accepted  TLSv1.1  128 bits  DHE-RSA-CAMELLIA128-SHA
Accepted  TLSv1.1  128 bits  EDH-RSA-DES-CBC3-SHA
Accepted  TLSv1.1  128 bits  AES128-SHA
Accepted  TLSv1.1  128 bits  CAMELLIA128-SHA
Accepted  TLSv1.1  128 bits  DES-CBC3-SHA
Accepted  TLSv1.1  128 bits  ECDHE-RSA-RC4-SHA
Accepted  TLSv1.1  128 bits  RC4-SHA
Accepted  TLSv1.1  128 bits  RC4-MD5
Accepted  TLSv1.2  256 bits  ECDHE-RSA-AES256-GCM-SHA384
Accepted  TLSv1.2  256 bits  ECDHE-RSA-AES256-SHA384
Accepted  TLSv1.2  256 bits  ECDHE-RSA-AES256-SHA
Accepted  TLSv1.2  256 bits  DHE-RSA-AES256-GCM-SHA384
Accepted  TLSv1.2  256 bits  DHE-RSA-AES256-SHA256
Accepted  TLSv1.2  256 bits  DHE-RSA-AES256-SHA
Accepted  TLSv1.2  256 bits  DHE-RSA-CAMELLIA256-SHA
Accepted  TLSv1.2  256 bits  AES256-GCM-SHA384
Accepted  TLSv1.2  256 bits  AES256-SHA256
Accepted  TLSv1.2  256 bits  AES256-SHA
Accepted  TLSv1.2  256 bits  CAMELLIA256-SHA
Accepted  TLSv1.2  128 bits  ECDHE-RSA-AES128-GCM-SHA256
Accepted  TLSv1.2  128 bits  ECDHE-RSA-AES128-SHA256
Accepted  TLSv1.2  128 bits  ECDHE-RSA-AES128-SHA
Accepted  TLSv1.2  128 bits  DHE-RSA-AES128-GCM-SHA256
Accepted  TLSv1.2  128 bits  DHE-RSA-AES128-SHA256
Accepted  TLSv1.2  128 bits  DHE-RSA-AES128-SHA
Accepted  TLSv1.2  128 bits  ECDHE-RSA-DES-CBC3-SHA
Accepted  TLSv1.2  128 bits  DHE-RSA-CAMELLIA128-SHA
Accepted  TLSv1.2  128 bits  EDH-RSA-DES-CBC3-SHA
Accepted  TLSv1.2  128 bits  AES128-GCM-SHA256
Accepted  TLSv1.2  128 bits  AES128-SHA256
Accepted  TLSv1.2  128 bits  AES128-SHA
Accepted  TLSv1.2  128 bits  CAMELLIA128-SHA
Accepted  TLSv1.2  128 bits  DES-CBC3-SHA
Accepted  TLSv1.2  128 bits  ECDHE-RSA-RC4-SHA
Accepted  TLSv1.2  128 bits  RC4-SHA
Accepted  TLSv1.2  128 bits  RC4-MD5

Expected results:

Depends on fix type, but at a minimum the disabling of SSLv3 and removal of any RC4, MD5 ciphers.

Client side probably also needs similar fix.

Additional info:

libvirtd provides no priority string to gnutls (gnutls_priority_init et al) so gnutls defaults to "NORMAL".  The global settings file is not triggered because that requires use of an '@' prefix.

Comment 1 Ján Tomko 2016-05-19 11:58:41 UTC
As said in: https://bugzilla.redhat.com/show_bug.cgi?id=1333404#c6

gnutls_set_default_priority should be giving applications both reasonable and configurable defaults.

Comment 2 Nikos Mavrogiannopoulos 2016-05-24 12:18:46 UTC
The default crypto settings in RHEL-6 will not change. As said in #1333404 this can be addressed in libvirt.

Comment 3 Jaroslav Suchanek 2016-05-30 13:13:57 UTC
The main discussion is part of bug 1333404. Based on that I am closing this for rhel-6.

Comment 4 Daniel Berrangé 2016-06-13 09:01:21 UTC
Re-opening per the RHEL-7 bug

Comment 9 yafu 2016-11-08 09:38:15 UTC
Verify the bug with build:

0.Prepare the tls env between hostA and hostB;

1.Set tls_priority to disable SSL3.0 in libvirtd.conf in the server and restart libvirtd service:
 #cat /etc/libvirt/libvirtd.conf

2.Edit libvirt.conf to only support SSL3.0 in libvirt.conf in the client:
  #cat /etc/libvirt/libvirt.conf

3.Connect to server hypervisor from client:
  #virsh -c qemu+tls://hostB/system
  error: authentication failed: TLS handshake failed A record packet with illegal version was received.
  error: failed to connect to the hypervisor

4.Edit libvirt.conf to other tls version except ssl3.0 in the client:
  #cat libvirt.conf

5.Connect to server hypervisor from client:
#virsh -c qemu+tls://hostB/system
Welcome to virsh, the virtualization interactive terminal.

Type:  'help' for help with commands
       'quit' to quit

virsh # 

6.Set tls_priority to the wrong values in the client:

7.Connect to server hypervisor from client:
   # virsh -c qemu+tls://hostB/system
error: failed to connect to the hypervisor
error: Failed to set TLS session priority to NORMAL:-VERS-TLS4.0: The request is invalid.

8.Also test TLS/protocol/cipher priority override in URI, the result is the same as setting tls_priority in libvirt.conf:
 #virsh -c qemu+tls://hostB/system?tls_priority=NORMAL:-VERS-ALL:+VERS-SSL3.0
error: authentication failed: TLS handshake failed A record packet with illegal version was received.
error: failed to connect to the hypervisor

#  virsh -c qemu+tls://hostB/system?tls_priority=NORMAL:-VERS-ALL:+VERS-TLS1.0
Welcome to virsh, the virtualization interactive terminal.

Type:  'help' for help with commands
       'quit' to quit

virsh # quit

#virsh -c qemu+tls://hostB/system?tls_priority=NORMAL:-VERS-TLS1.3
error: failed to connect to the hypervisor
error: Failed to set TLS session priority to NORMAL:-VERS-TLS1.3: The request is invalid.

9.Also test setting tls_priority to only support TLS1.2 in the server side, the client also needs to set tls_priority to only support TLS1.2 to connect to the server correctly.

Comment 15 errata-xmlrpc 2017-03-21 10:39:08 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.


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