Bug 1563585 - [RFE][qemu] Need the ability to set which TLS version the spice connection will use.
Summary: [RFE][qemu] Need the ability to set which TLS version the spice connection wi...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev
Version: 7.6
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Gerd Hoffmann
QA Contact: Guo, Zhiyi
URL:
Whiteboard:
Depends On: 1562213
Blocks: 1477664 1558125 1562212 1563271
TreeView+ depends on / blocked
 
Reported: 2018-04-04 08:50 UTC by Martin Tessun
Modified: 2018-07-03 02:11 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of: 1562213
Environment:
Last Closed: 2018-06-22 06:12:46 UTC
Target Upstream Version:


Attachments (Terms of Use)

Comment 2 Gerd Hoffmann 2018-04-05 15:50:02 UTC
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?

Comment 4 Daniel Berrangé 2018-04-05 15:59:23 UTC
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.

Comment 5 Gerd Hoffmann 2018-04-06 06:23:37 UTC
> 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).

Comment 6 Christophe Fergeau 2018-04-06 08:45:31 UTC
(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.

Comment 7 Gerd Hoffmann 2018-04-06 09:52:55 UTC
  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.

Comment 8 Christophe Fergeau 2018-05-24 15:42:01 UTC
(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.

Comment 11 Christophe Fergeau 2018-06-22 06:12:46 UTC
(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 ;)


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