Provide a way to do TLS first in QEMU/NBD connections (not after NBD negotiation)
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:
- Clear indication to a network observer that NBD (and therefore likely qemu/libvirt) is used. In contrast, TLS1.3 hides even the SNI of the servers (ESNI, https://blog.cloudflare.com/encrypted-sni/).
- Potential for bugs in NBD protocol negotiation code. That code just statistically, likely less looked at code than gnutls.
- MITM downgrade attacks, as explained at https://serverfault.com/questions/523804/is-starttls-less-safe-than-tls-ssl, applicable to STARTTLS, but fundamentals are the same here. This is the most serious problem.
It's very unlikely that it's currently safe to run QEMU migration stream over a hostile network, but it should be possible to do with TLS only option.
Solution to this, just like in the case of SMTP, is to provide TLS only option (no initial cleartext at all) for QEMU migration.
This should work really well with #66 (closed) #67 (closed)