diff options
Diffstat (limited to 'results/classifier/118/permissions/1894781')
| -rw-r--r-- | results/classifier/118/permissions/1894781 | 159 |
1 files changed, 159 insertions, 0 deletions
diff --git a/results/classifier/118/permissions/1894781 b/results/classifier/118/permissions/1894781 new file mode 100644 index 00000000..35f46da7 --- /dev/null +++ b/results/classifier/118/permissions/1894781 @@ -0,0 +1,159 @@ +semantic: 0.953 +permissions: 0.951 +assembly: 0.947 +register: 0.945 +debug: 0.940 +network: 0.938 +PID: 0.931 +graphic: 0.927 +architecture: 0.925 +performance: 0.924 +device: 0.922 +boot: 0.907 +arm: 0.904 +user-level: 0.892 +peripherals: 0.889 +VMM: 0.885 +hypervisor: 0.863 +virtual: 0.848 +files: 0.839 +socket: 0.819 +kernel: 0.815 +risc-v: 0.814 +ppc: 0.798 +KVM: 0.766 +vnc: 0.705 +TCG: 0.687 +mistranslation: 0.673 +x86: 0.650 +i386: 0.543 + +[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! + +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 + + + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + + +This is an automated cleanup. This bug report has been moved to QEMU's +new bug tracker on gitlab.com and thus gets marked as 'expired' now. +Please continue with the discussion here: + + https://gitlab.com/qemu-project/qemu/-/issues/282 + + |