Re: [libvirt] [libvirt PATCH] qemu: Add support for specifying SPICE TLS ciphers
On Wed, Apr 04, 2018 at 09:11:25AM +0100, Daniel P. Berrangé wrote:
On Tue, Apr 03, 2018 at 08:11:05PM +0200, Jiri Denemark wrote:
> On Tue, Apr 03, 2018 at 17:23:50 +0200, Ján Tomko wrote:
> > From: Christophe Fergeau <cfergeau(a)redhat.com>
> >
> > This commit adds a 'spice_tls_ciphers' parameter in
> > qemu.conf which allows to configure which TLS ciphers
> > SPICE will be using for its TLS connections.
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1562032
> >
> > Signed-off-by: Christophe Fergeau <cfergeau(a)redhat.com>
> > Signed-off-by: Ján Tomko <jtomko(a)redhat.com>
> > ---
> > This is mostly useful as a workaround for missing crypto policies,
> > so I'm not sure if it's upstream material.
>
> Are OpenSSL crypto policies supported upstream? If so, I think we should
> just rely on them and leave this workaround for downstreams if they want
> it.
--system-ciphers-file support seems to be a fedora patch
(openssl-1.1.0-system-cipherlist.patch), I could not find it in the
upstream git.
Something I realized recently is that OpenSSL crypto policies as they
are now in Fedora only allow to configure TLS ciphers, you cannot
enable/disable TLS protocol versions. This is possible with the gnutls
crypto policies.
>Also, what would we do if spice changed its TLS code to use
another
> library, wouldn't it force us to translate the parameters from OpenSSL
> to the other library if this happens and this code is merged upstream?
The latter is actually my biggest concern with this. I would really like
to get SPICE to use the QEMU TLS creds framework, so we can do the normal
-object tls-creds-x509 ... setup as we do for other parts ofo QEMU. This
would mean SPICE using GNUTLS format for specifying ciphers. In fact the
GNUTLS format specifies ciphers and TLS protocol versions - both of which
the quoted bug is asking for - whereas this patch only specifies ciphers
Yes, I also want to explore making use of -object tls-creds-x509 for
SPICE. However, if doing that, it seems better to go the whole way, and
let QEMU do the socket handling including TLS, which is probably some
longer term work
I also have a set of patches to address the TLS version issue, which
adds a -spice tls-min-version command line option, and another libvirt
qemu.conf option.
I can definitely spend more time on -object tls-creds-x509 support
before we decide whether to move forward one way or the other.
Another stop gap solution I was thinking of, but which I'm not sure it
would work would be to extend <qemu:commandline> so that we can use it
to append options to existing commandline parameters, rather than always
adding a new parameter with the option. If there had been a way to
generate
-spice $libvirt_generated_args,tls-ciphers=xxxx rather than
-spice $libvirt_generated_args -spice tls-ciphers=xxxx , I don't think
https://bugzilla.redhat.com/show_bug.cgi?id=1562032 would have been
opened.
Christophe
Attachments:
- signature.asc (application/pgp-signature — 833 bytes)