Re: [Bug 1894781] [NEW] [Feature request] Provide a way to do TLS first in QEMU/NBD connections (not after NBD negotiation)

[Eric Blake]

On 9/7/20 11:00 PM, Vjaceslavs Klimovs wrote:
> Public bug reported:
>
> (following from
> https://gitlab.com/libvirt/libvirt/-/issues/68#note_400960567)
>
> As is very well explained in https://www.berrange.com/posts/2016/04/05
> /improving-qemu-security-part-5-tls-support-for-nbd-server-client/, and
> easily confirmed with captures, NBD stream starts in cleartext and
> upgrades to TLS inline (similar to STARTTLS mechanism). As a rationale,
> it is stated that this provides better error messages for the user of
> NBD.
>
> However, this approach has downsides:
>
> 1) Clear indication to a network observer that NBD (and therefore likely 
> qemu/libvirt) is used.

qemu/libvirt is not the only client of NBD.  In fact, the nbdkit and 
libnbd projects exist to make it easier to utilize NBD from more places.

> In contrast, TLS1.3 hides even the SNI of the servers (ESNI, 
> https://blog.cloudflare.com/encrypted-sni/).
> 2) Potential for bugs in NBD protocol negotiation code. That code just 
> statistically, likely less looked at code than gnutls. This is not a reflection 
> on NBD code quality, just the fact that TLS code does receive a bit more 
> scrutiny.

This is a non-argument.  When configured correctly at the NBD server, 
the NBD_OPT_STARTTLS option is the _only_ option accepted by a client, 
at which point you are right back into TLS code (from gnutls or 
elsewhere) and using the existing TLS libraries to establish the 
connection - but that is the SAME thing you would have to do even if 
there were a way to connect to an NBD server that doesn't even start 
with plaintext handshaking.

> 3) Inability to inspect TLS listener interface for compliance, e.g. with a 
> security scanner. Making sure TLS listeners only select certain ciphersuits is 
> a requirement of some compliance regimes.
>
> I think it's fully possible to satisfy the original requirement of good
> error messages as well, detecting that the other end is initiating TLS
> connection.

If you are going to make a change in this area, it will need to be 
agreed on in the upstream NBD list, where _all_ implementations of NBD 
(both client and server) can weigh in; qemu will not change in a vacuum 
without upstream protocol concurrence.

https://lists.debian.org/nbd/

> It's very unlikely that it's currently sae to recommend to run QEMU
> migration stream over a hostile network, but it should be possible to do
> with TLS only option.

It is very easy to write both servers and clients that require a 
transition from plaintext into TLS before any serious traffic is sent.

> Solution to this, just like in the case of SMTP, is to provide TLS only
> option (no initial cleartext at all) for QEMU migration, which hopefully
> it not a large addition.
>
> Thank you for your consideration!
>
> ** Affects: qemu
>       Importance: Undecided
>           Status: New

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org