[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug 1894781] [NEW] [Feature request] Provide a way to do TLS first in Q
From: |
Vjaceslavs Klimovs |
Subject: |
[Bug 1894781] [NEW] [Feature request] Provide a way to do TLS first in QEMU/NBD connections (not after NBD negotiation) |
Date: |
Tue, 08 Sep 2020 04:00:01 -0000 |
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. 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!
** Affects: qemu
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1894781
Title:
[Feature request] Provide a way to do TLS first in QEMU/NBD
connections (not after NBD negotiation)
Status in QEMU:
New
Bug description:
(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!
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1894781/+subscriptions
- [Bug 1894781] [NEW] [Feature request] Provide a way to do TLS first in QEMU/NBD connections (not after NBD negotiation),
Vjaceslavs Klimovs <=