Red Hat Bugzilla – Bug 1029226
[RFE] Allow only strong ciphers for spice. (depends on platform crypto policy implementation)
Last modified: 2017-09-28 05:28:34 EDT
Description of problem:
SPICE uses the default cipher list from openssl, When a client connect to the hypervisor using SPICE, a cipher is chosen among that list (client sends the list of ciphers it supports, server picks one in that list).That default list contains some strong ciphers first, and then some medium strength one.
Its been seen many time client sends medium strength list to spice server and server chose those medium strength ciphers for spice. Unfortunately there is no way to configure what ciphers to be used by SPICE on RHEV-H.
Many organization now days becoming strict about cipher strength. Security compliance restrict to use strong cipher for greater security. e.g Government organisations.
We should allow only strong ciphers for spice, complete remove list of medium strength ciphers os provide a config parameter to force use strong ciphers only like httpd has (https://access.redhat.co/site/solutions/430853)
Version-Release number of selected component (if applicable):
Red Hat Enterprise Virtualization 3.X
tls-ciphers QEMU option can be used, however it's not exposed in libvirt, AFAICT.
Would it require libvirt changes or can we do that in qemu.conf?
Libvirt does not support tls-ciphers in any way so yes, libvirt changes will be required. However, the changes to support it should not be too big.
opened libvirt bug for the feature
would system-wide disablement of the weak ciphers be ok?
Bug 1084024 has been closed|notabug in favour of http://fedoraproject.org//wiki/Changes/CryptoPolicy (which is not on el7).
I don't think that we have a choice but to follow suit.
This bug did not make it in time for 3.6 release, moving out
Will this allow specifying a specific cipher supported by the AES-NI extensions such as aes128-cbc, as the first cipher to be negotiated?
I gained a massive improvement in performance for X11 over SSH in our environment by switching to aes128-cbc as first negotiated cipher, and I was hoping for an increase in performance for SPICE as well.
(In reply to Sigbjorn Lie from comment #10)
> Will this allow specifying a specific cipher supported by the AES-NI
> extensions such as aes128-cbc, as the first cipher to be negotiated?
> I gained a massive improvement in performance for X11 over SSH in our
> environment by switching to aes128-cbc as first negotiated cipher, and I was
> hoping for an increase in performance for SPICE as well.
all the TLS ciphers that use AES, that is AES-128-CBC, AES-256-CBC, AES-128-GCM and AES-256-GCM will use AES-NI in OpenSSL
AES ciphers are also placed first in OpenSSL cipher order, so I don't know how your connection could end up using cipher that doesn't already use AES-NI acceleration without either end using very atypical list of ciphers
why do you think it doesn't use AES-NI now?