Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
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

Summary: libvirtd allows SSLv3 connections and poor ciphers
Product: Red Hat Enterprise Linux 6 Reporter: Martin Poole <mpoole>
Component: libvirtAssignee: Ján Tomko <jtomko>
Status: CLOSED ERRATA QA Contact: yafu <yafu>
Severity: high Docs Contact: Yehuda Zimmerman <yzimmerm>
Priority: unspecified    
Version: 6.8CC: ailan, berrange, jsuchane, jtomko, libvirt-maint, rbalakri, rjones, virt-bugs, xuzhang, yafu, yalzhang
Target Milestone: rcKeywords: Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
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.
 Story Points: ---
Clone Of: 1333404 Environment:
Last Closed: 2017-03-21 10:39:08 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1333404    
Bug Blocks: 1269194, 1339222, 1343211, 1359965, 1364808    

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):

  libvirt-1.2.17-13.el7_2.4

How reproducible:

Always

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:
libvirt-0.10.2-62.el6.x86_64
libvirt-client-0.10.2-62.el6.x86_64
gnutls-2.12.23-17.el6.x86_64


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
  tls_priority="NORMAL:!VERS-SSL3.0"

2.Edit libvirt.conf to only support SSL3.0 in libvirt.conf in the client:
  #cat /etc/libvirt/libvirt.conf
 tls_priority=NORMAL:-VERS-ALL:+VERS-SSL3.0

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
 tls_priority=NORMAL:-VERS-ALL:+VERS-TLS1.0

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:
   tls_priority="NORMAL:-VERS-SSL4.0"

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.

https://rhn.redhat.com/errata/RHBA-2017-0682.html