1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
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!
|