diff options
Diffstat (limited to 'results/classifier/105/semantic/1809252')
| -rw-r--r-- | results/classifier/105/semantic/1809252 | 60 |
1 files changed, 60 insertions, 0 deletions
diff --git a/results/classifier/105/semantic/1809252 b/results/classifier/105/semantic/1809252 new file mode 100644 index 00000000..8e40776b --- /dev/null +++ b/results/classifier/105/semantic/1809252 @@ -0,0 +1,60 @@ +semantic: 0.906 +other: 0.894 +device: 0.862 +mistranslation: 0.842 +instruction: 0.785 +network: 0.783 +vnc: 0.776 +socket: 0.701 +graphic: 0.653 +assembly: 0.541 +KVM: 0.539 +boot: 0.515 + +Password authentication in FIPS-compliant mode + +The documentation states, that: + +"The VNC protocol has limited support for password based authentication. (...) Password authentication is not supported when operating in FIPS 140-2 compliance mode as it requires the use of the DES cipher." + +Would it be possible for qemu to use a different cipher and re-enable password as an option in VNC console? Is there a technical reason for not using a stronger cipher? + +On 12/20/18 6:59 AM, Tomasz Barański wrote: +> Public bug reported: +> +> The documentation states, that: +> +> "The VNC protocol has limited support for password based authentication. +> (...) Password authentication is not supported when operating in FIPS +> 140-2 compliance mode as it requires the use of the DES cipher." +> +> Would it be possible for qemu to use a different cipher and re-enable +> password as an option in VNC console? Is there a technical reason for +> not using a stronger cipher? + +The technical reason is that there are no other VNC endpoints out there +that support a different cipher. The VNC protocol itself declares what +all compliant servers/clients must use - and that spec is what makes the +non-FIPS-compliant requirement. You wouldn't have to patch just qemu, +but every other VNC endpoint out there that you want to interoperate +with a patched qemu. But it's really not worth doing that when there +are already better solutions available. That is, rather than trying to +fix VNC, just use an alternative protocol that doesn't have a baked-in +authentication limitation in the first place - namely, Spice. + +-- +Eric Blake, Principal Software Engineer +Red Hat, Inc. +1-919-301-3266 +Virtualization: qemu.org | libvirt.org + + +The VNC password authentication scheme is not extensible. It is unfixably broken by design. + +QEMU provides the SASL authentication scheme for VNC which allows for strong authentication, when combined with the VeNCrypt authentication scheme that uses TLS. + +These extensions are supported by the gtk-vnc client used by remote-viewer, virt-viewer, virt-manager, GNOME Boxes and more. Other VNC clients are also known to implement VeNCrypt, though SASL support is less wide spread. + +From a QEMU POV, there's nothing more we need todo really - any remaining gaps are client side. + +I understand. Thank you, guys! + |