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@xxxxxxxxxx> > > > > > > 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@xxxxxxxxxx> > > > Signed-off-by: Ján Tomko <jtomko@xxxxxxxxxx> > > > --- > > > 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
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
