Bug 1563585

Ok, so spice-server must implement that and export a new function which qemu can use to configure is according to the users wishes.

Question is what we are going to do on the qemu side.  One obvious way is to just add a new config option to -spice.  Qemu itself supports tls too though, for example for vnc and tcp chardevs (serial console).  So it makes sense to allow configuring the tls version for these too.  Again multiple possible approaches:  Configure per connection, or have a global switch.

I'd tend to prefer a global switch.  I can't think of a useful use case where it makes sense to limit spice to TLS 1.3+ but allow older TLS versions for other connections.

Cc'ing Daniel who worked on qemu tls support recently.

Comments?

The existing TLS support for VNC, chardevs, migration and NBD uses the --object tls-creds-x509  approach, which already includes the 'priority' option that accepts a GNUTLS priority string - this covers both ciphers & TLS versions.

In addition to that, GNUTLS supports global crypto policies, and we compile QEMU with a default priority of  "@QEMU,SYSTEM" in Fedora.

IOW, for anything using GNUTLS, we already have the ability to set TLS priority globally for all software on the host, globally for every QEMU instance on the host, and on a per-network service option for individual QEMU processes.

Now the crypto policies stuff only exists in Fedora & future RHEL, not RHEL-7.x, so you can't use that yet. From upstream POV, I see no compelling reason to invent yet another way of configuring GNUTLS defaults just to deal with fact that RHEL-7 hasn't backported the crypto policy framework that's in Fedora.

From upstream POV, SPICE is a problem because it uses OpenSSL rather than GNUTLS, so even with crypto policies support, you wouldn't be able to configure TLS version, only ciphers. I think the right solution upstream is for SPICE to offload the TLS I/O to QEMU, so it gets feature parity with VNC, chardevs, migration & NBD.

> From upstream POV, SPICE is a problem because it uses OpenSSL rather than
> GNUTLS, so even with crypto policies support, you wouldn't be able to
> configure TLS version, only ciphers. I think the right solution upstream is
> for SPICE to offload the TLS I/O to QEMU, so it gets feature parity with
> VNC, chardevs, migration & NBD.

I suspect switching spice to use gnutls instead of openssl would be alot easier.
Spice could likewise use the global TLS priority then.  And we don't have to put the spice-server library api upside-down then (which would be needed when moving all TLS processing from spice-server to qemu).

(In reply to Gerd Hoffmann from comment #5)
> > From upstream POV, SPICE is a problem because it uses OpenSSL rather than
> > GNUTLS, so even with crypto policies support, you wouldn't be able to
> > configure TLS version, only ciphers. I think the right solution upstream is
> > for SPICE to offload the TLS I/O to QEMU, so it gets feature parity with
> > VNC, chardevs, migration & NBD.
> 
> I suspect switching spice to use gnutls instead of openssl would be alot
> easier.
> Spice could likewise use the global TLS priority then.  And we don't have to
> put the spice-server library api upside-down then (which would be needed
> when moving all TLS processing from spice-server to qemu).

Even if spice uses gnutls (and I don't know if such a change would be doable/desirable in 7.6 timeframe), this will not give us configurable TLS protocol/ciphers in RHEL7. There are customers who need to disable TLSv1.1 now, and there are currently no way of doing that short of rebuilding spice-server.

  Hi,

> > I suspect switching spice to use gnutls instead of openssl would be alot
> > easier.
> > Spice could likewise use the global TLS priority then.  And we don't have to
> > put the spice-server library api upside-down then (which would be needed
> > when moving all TLS processing from spice-server to qemu).
> 
> Even if spice uses gnutls (and I don't know if such a change would be
> doable/desirable in 7.6 timeframe), this will not give us configurable TLS
> protocol/ciphers in RHEL7. There are customers who need to disable TLSv1.1
> now, and there are currently no way of doing that short of rebuilding
> spice-server.

We can add a -spice priority=... option, which accepts a gnutls priority string, like --object tls-creds-x509,priority=... does.  So it'll be configurable, even if the global policy isn't available.

Possibly we can do that even without switching to gnutls, by having spice-server understanding the needed subset of gnutls priority strings to disable certain tls versions ("-VERS-TLS1.0" for example) and configure openssl accordingly.  Which of course only makes sense if the long-term plan is to actually switch over to gnutls and use this only as temporary stopgap to make the 7.6 deadline.

(In reply to Gerd Hoffmann from comment #7)
>   Hi,
> 
> > > I suspect switching spice to use gnutls instead of openssl would be alot
> > > easier.
> > > Spice could likewise use the global TLS priority then.  And we don't have to
> > > put the spice-server library api upside-down then (which would be needed
> > > when moving all TLS processing from spice-server to qemu).
> > 
> > Even if spice uses gnutls (and I don't know if such a change would be
> > doable/desirable in 7.6 timeframe), this will not give us configurable TLS
> > protocol/ciphers in RHEL7. There are customers who need to disable TLSv1.1
> > now, and there are currently no way of doing that short of rebuilding
> > spice-server.
> 
> We can add a -spice priority=... option, which accepts a gnutls priority
> string, like --object tls-creds-x509,priority=... does.  So it'll be
> configurable, even if the global policy isn't available.
> 
> Possibly we can do that even without switching to gnutls, by having
> spice-server understanding the needed subset of gnutls priority strings to
> disable certain tls versions ("-VERS-TLS1.0" for example) and configure
> openssl accordingly.  Which of course only makes sense if the long-term plan
> is to actually switch over to gnutls and use this only as temporary stopgap
> to make the 7.6 deadline.

I've asked for feedback from the crypto team to see how/when they intend to support TLS version configuration in openssl crypto policies, depending on their answer, I might go with the same format as what they'd use in the openssl crypto policy configuration.

If they don't have a clear plan for that, re-using the gnutls format just for version selection sounds like a very good suggestion. If we go for a downstream only stopgap, I"m tempted to not even bother with a qemu command line option, but just parse (with a downstream patch) a /etc/crypto-policies/back-ends/gnutls-spice.config file which is what you would use on Fedora to configure a gnutls spice crypto policy.

Porting spice to gnutls does not seem too hard, however this would break the pre-existing -spice tls-ciphers=xxx argument, which some customers are currently using through vdsm hooks, so I'd prefer not to break this in RHEL7.

(In reply to Gerd Hoffmann from comment #10)
> Quoting bug 1562213:
> 
> So spice-server using a config file implies we don't have to do anything in
> qemu (and higher up the management stack).
> 
> So, closing as notabug?  Or another reason?

Yes, this definitely can be closed, I guess NOTABUG would work, I always have a hard time finding the right resolutino ;)