Bug 1333404

Nikos, before any further actions in libvirt, may I ask you for your explanation/recommendation regarding "weak" ciphers in gnutls like SSLv3 which are by default enabled in gnutls?

Libvirt simply uses gnutls_set_default_priority() which is the recommendation given in https://fedoraproject.org/wiki/Packaging:CryptoPolicies to make it use the system default policies for crypto ciphers / protocols.  So if libvirt is showing SSLv3 enabled, that's because the system policy has enabled it. Libvirt shouldn't need any configuration of its own to customize ciphers/protocols if the system policy is working correctly in RHEL

(In reply to Daniel Berrange from comment #3)
> Libvirt simply uses gnutls_set_default_priority() which is the
> recommendation given in
> https://fedoraproject.org/wiki/Packaging:CryptoPolicies to make it use the
> system default policies for crypto ciphers / protocols.  So if libvirt is
> showing SSLv3 enabled, that's because the system policy has enabled it.
> Libvirt shouldn't need any configuration of its own to customize
> ciphers/protocols if the system policy is working correctly in RHEL

While the above is correct I was not able to find any straightforward way how to change the cipher system policy in RHEL (besides enforcing fips140-2, where I am not sure what impact it has on gnutls). Seems like having an option in libvirt's configuration file and using gnutls_priority_set_direct() might help.

Jano can you please take care of this one, thanks.

Proposed upstream patch adding a configuration option for the priorities:
https://www.redhat.com/archives/libvir-list/2016-May/msg01345.html

The upstream patch was rejected as it would only allow to work around the problem for libvirt, not other applications using gnutls.

gnutls_set_default_priority should be giving us both reasonable and configurable defaults.

Not all applications need to adhere to PCI-DSS. If we fix that globally without co-ordination we will break use cases that require SSL 3.0. If it is an urgent issue in libvirt it cannot be solved by the gnutls component.

The original bug description here is merely complaining there is no mechanism to change the default cipher/protocol selection in libvirt, not asking to actually change the out of the box defaults.

Libvirt simply uses gnutls_set_default_priority() on the basis, that this makes it honour gnutls' global defaults. Assuming gnutls global defaults can be changed by an admin deploying RHEL (eg via /etc/crypto-policies/config or an equivalent RHEL specific method), then IMHO this can be NOTABUG.

(In reply to Daniel Berrange from comment #8)

> Libvirt simply uses gnutls_set_default_priority() on the basis, that this
> makes it honour gnutls' global defaults. Assuming gnutls global defaults can
> be changed by an admin deploying RHEL (eg via /etc/crypto-policies/config or
> an equivalent RHEL specific method), then IMHO this can be NOTABUG.

We do not have any equivalent RHEL specific method to configure system wide policy (that's only in Fedora and incomplete as it doesn't yet cover Java and NSS). As I mentioned before we plan to introduce that in RHEL-7.5 for all the crypto libraries (gnutls/openssl/NSS/Java) so that everything is consistent. We can discuss about bringing that sooner (RHEL-7.4), but that cannot address an urgent customer issue.

(In reply to Nikos Mavrogiannopoulos from comment #9)
> (In reply to Daniel Berrange from comment #8)
> 
> > Libvirt simply uses gnutls_set_default_priority() on the basis, that this
> > makes it honour gnutls' global defaults. Assuming gnutls global defaults can
> > be changed by an admin deploying RHEL (eg via /etc/crypto-policies/config or
> > an equivalent RHEL specific method), then IMHO this can be NOTABUG.
> 
> We do not have any equivalent RHEL specific method to configure system wide
> policy (that's only in Fedora and incomplete as it doesn't yet cover Java
> and NSS). As I mentioned before we plan to introduce that in RHEL-7.5 for
> all the crypto libraries (gnutls/openssl/NSS/Java) so that everything is
> consistent. We can discuss about bringing that sooner (RHEL-7.4), but that
> cannot address an urgent customer issue.

If its planned for a RHEL update, then from libvirt I'd rather we just wait for that update to arrive and, if needed focus effort on accelerating that, rather than inventing yet more application specific config flags

Given the discussion above I'm inclined to move this bug back to libvirt. There is no way gnutls can help libvirt have customized settings while using the default options. You may want to wait until the global defaults are satisfactory to the client with the support case, but the bug should remain to libvirt and be blocked to the global default change (which is planned for 7.5.0, thus no bug yet). I'll reassign the bug today, unless there is an objection.

Public security articles now published noting that it is not possible to adequately secure libvirt for remote connections.

Re-opening, since there is definitely a gap here that we've identified - it just isn't yet 100% clear how we want to solve it long term. I'll be sending a mail to gnutls dev mailing list to discuss some possibilities in near future.

I've sent a patch to gnutls upstream to better handle application specific overrides & fallbacks with the global priorities file

  http://lists.gnutls.org/pipermail/gnutls-devel/2016-June/008007.html

if gnutls accepts this, then we could modify libvirt to call

  gnutls_priority_set_direct(session, "@LIBVIRT,SYSTEM", NULL);

by default (similarly for QEMU + GTK-VNC). 

Combined with this enhancement to the fedora crypto-policy generator:

  https://github.com/nmav/fedora-crypto-policies/pull/3

We would enable sys admins todo per-application customization of cipher policies in the global configuration file, without needing to ever touch libvirt/qemu/gtk-vnc config files directly.

Of course, we probably still need to add support for direct customization in libvirt to facilitate use with older gnutls versions that already exist in distros, but for the long term, this proposed solution will be much nicer.

The libvirt part of this is addressed in

8dfb796080de822bf0525ae8c83f7b704abe9375 Use @SYSTEM priority for TLS on Fedora >= 21
6d310c9cffa08ed7e1ea2d57113929dc831702bf remote: allow TLS priority to be customized
5f1837eaca4beba418ea75ce5ee9ec235e277fa2 Pass config file object through to driver open methods
416358d99df0929a3901735c557bda8f393820ea remote: allow TLS protocol/cipher priority override in URI
c7d0fbe62b0f59b08d0f140e58e48f9837fe8476 libvirtd: add config option for TLS priority
214489f550b95e4accf55896afb39a45be1175df rpc: allow priority string to be passed to TLS context
cbb2e91ecc56d218ca20c1a9ba345eaf754d6c5d configure: allow setting default TLS priority string
20c5ded9d013e8186e98e36ef62aea2e86f5c2f3 rpc: set gnutls log function at global init time
d8a8af3492194089d1f101e10305421fba2d1760 tls: remove support for gnutls 1.x.x, require 2.2.0


Fixing the QEMU side is non-trivial effort, since it'll require a complete change in the way we configure QEMU TLS

Also one followup

19aee2cb9af340e12a4552405ba271054263ac37 libvirt.spec.in: include NORMAL as a fallback for @SYSTEM in TLS prio

The most recent commit from comment 19 relevant to RHEL:
commit 6d310c9cffa08ed7e1ea2d57113929dc831702bf
Author:     Daniel P. Berrange <berrange>
CommitDate: 2016-06-08 13:48:45 +0100

    remote: allow TLS priority to be customized

git describe: v1.3.5-97-g6d310c9

Verify the bug with libvirt-2.0.0-6.el7.x86_64.

Scenerio1 Test the tls_priority config in the libvirt.conf:
0.Prepare the tls env between hostA and hostB;

1.Set tls_priority in libvirt.conf:
  tls_priority="NORMAL:-VERS-SSL3.0"

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

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

 virsh # 

3.Also test tls_priority as "NORMAL:-VERS-TLS1.0","NORMAL:-VERS-TLS1.1","NORMAL:-VERS-TLS1.2",can connect to server hypervisor correctly.

4.Set tls_priority to the wrong values:
   tls_priority="NORMAL:-VERS-SSL4.0"

5.Connect to server hypervisor:
   # 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.

6.Also test tls_prioprity as " "，"-VERS-TLS1.1",".", then connect to server hypervisor, both libvirtd and virsh client works well.


Scenerio2 Test TLS protocol/cipher priority override in URI:
1.Override TLS priority in URI with right value:
  #virsh -c qemu+tls://hostB/system?tls_priority=NORMAL:-VERS-SSL3.0
Welcome to virsh, the virtualization interactive terminal.

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

virsh # 

2.Also test tls_priority as "NORMAL:-VERS-TLS1.0","NORMAL:-VERS-TLS1.1","NORMAL:-VERS-TLS1.2",can connect to server hypervisor correctly.

3.Override TLS priority in URI with wrong value:
 #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.

Hi,Daniel,

Since @SYSTEM priority for TLS is not supported in rhel7.3, would you help to check the steps in comment 28 are enough for verifying this bug? Thanks a lot.

That is fine - gnutls in RHEL-7 doesn't yet support the @BLAH style strings.

Move the bug to VERIFIED according comment 28.

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/RHSA-2016-2577.html

*** Bug 1578050 has been marked as a duplicate of this bug. ***