Bug 1029226 - [RFE] Allow only strong ciphers for spice. (depends on platform crypto policy implementation)
[RFE] Allow only strong ciphers for spice. (depends on platform crypto policy...
Status: NEW
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: RFEs (Show other bugs)
unspecified
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Rob Young
Shai Revivo
: FutureFeature
Depends On: 1237227 1084024
Blocks: 1252923
  Show dependency treegraph
 
Reported: 2013-11-11 17:43 EST by Prasad Mukhedkar
Modified: 2017-09-28 05:28 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
: 1084024 1237227 (view as bug list)
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Virt
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
sherold: Triaged+


Attachments (Terms of Use)

  None (edit)
Description Prasad Mukhedkar 2013-11-11 17:43:38 EST
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
SPICE
Comment 2 Michal Skrivanek 2014-04-02 05:50:49 EDT
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?
Comment 3 Jiri Denemark 2014-04-03 07:45:45 EDT
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.
Comment 4 Michal Skrivanek 2014-04-03 08:46:39 EDT
opened libvirt bug for the feature
Comment 5 Michal Skrivanek 2014-07-15 10:29:54 EDT
would system-wide disablement of the weak ciphers be ok?
Comment 8 Dan Kenigsberg 2015-05-12 04:52:55 EDT
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.
Comment 9 Michal Skrivanek 2015-06-05 08:13:43 EDT
This bug did not make it in time for 3.6 release, moving out
Comment 10 Sigbjorn Lie 2015-12-23 05:27:02 EST
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.
Comment 11 Hubert Kario 2016-03-22 13:54:08 EDT
(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?

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