summary refs log tree commit diff stats
path: root/results/scraper/launchpad-without-comments/1894781
diff options
context:
space:
mode:
Diffstat (limited to 'results/scraper/launchpad-without-comments/1894781')
-rw-r--r--results/scraper/launchpad-without-comments/189478119
1 files changed, 19 insertions, 0 deletions
diff --git a/results/scraper/launchpad-without-comments/1894781 b/results/scraper/launchpad-without-comments/1894781
new file mode 100644
index 000000000..8b0a061f3
--- /dev/null
+++ b/results/scraper/launchpad-without-comments/1894781
@@ -0,0 +1,19 @@
+[Feature request] Provide a way to do TLS first in QEMU/NBD connections (not after NBD negotiation)
+
+(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. 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. 
+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.
+
+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.
+
+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!
\ No newline at end of file