GNOME Bugzilla – Bug 728267
Support new VNC security types
Last modified: 2020-11-12 12:24:25 UTC
Since a recent update, it is impossible to connect to my Ubuntu box using VNC from a Windows machine unless I disable encryption on the vino server. I tested up-to-date tightVNC client and TigerVNC client on the Windows machine, with the same result. As soon I try to connect, I receive the following error: [ 5872/ 6448] 2014-01-20 12:11:18:247 List of security type is read [ 5872/ 6448] 2014-01-20 12:11:18:247 : Security Types received (1): Unknown type (18) [ 5872/ 6448] 2014-01-20 12:11:18:247 Selecting auth-handler [ 5872/ 6448] 2014-01-20 12:11:18:247 + RemoteViewerCore. Exception: No security types supported. Server sent security types, but we do not support any of their. So it seems that the update changed the security type of vino to a new one. I searched for a way to go back to the old one (until the clients catches up) with no avail. A solution is disabling the encryption completely, by gsettings set org.gnome.Vino require-encryption false ...but this is subotpimal. Is there a way to switch the encryption back to the old one? References of the bug on Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=981984 And on Ubuntu/Launchpad: https://bugs.launchpad.net/ubuntu/+source/vino/+bug/1281250 I mentioned the problem in TigerVNC tracking system: https://sourceforge.net/p/tigervnc/bug-tracker/148/
Vino should work fine with security type 18, but there have been a couple of changes to the authentication code that might have affected it: https://git.gnome.org/browse/vino/commit/?id=860337231eaccfeed4f857afd0579546a260c23f https://git.gnome.org/browse/vino/commit/?id=3b38cf49321924ff2ec657a6e4db8a1932245ef9 However, both of those changes were made after 3.8, which was the version mentioned in the Fedora bug report. If you can find the point at which you could no longer connect to Vino, that would make it easier to track down the bug.
The problem for me is with the version 3.10.0 which came with the gnome 3.10 update for Ubuntu. It worked before my update to Ubuntu 13.10, so it should be between 3.6.2 and 3.10 (I know, too broad). [:~] 127 % apt-cache policy vino vino: Installed: 3.10.0-0ubuntu1~saucy1 Candidate: 3.10.0-0ubuntu1~saucy1 Version table: *** 3.10.0-0ubuntu1~saucy1 0 500 http://ppa.launchpad.net/gnome3-team/gnome3-staging/ubuntu/ saucy/main i386 Packages 100 /var/lib/dpkg/status 3.6.2-0ubuntu5 0 500 http://archive.ubuntu.com/ubuntu/ saucy/main i386 Packages Will ask on the launchpad bug if we can have a map of versions. Thanks. If I can help enabling some debugging, explain me how, and I will try to do it. I do not have a lot of time now as to recompile things, but re-enabling encryption and sending logs is quite feasible.
I guess that the problem occurs after the default was changed to require encryption: https://git.gnome.org/browse/vino/commit/?id=f37ca213fda500ea2f93d005e945644c2f2e5721 For whatever reason, that fails with some clients. If you want Vino to work with those clients new authentication types need to be added. There is some information about the protocol and security types at: http://sourceforge.net/p/tigervnc/code/HEAD/tree/rfbproto/rfbproto.rst I will not have time to add the security types in the near future.
(In reply to comment #3) > For whatever reason, that fails with some clients The reason is that the client does not support the security type, of course.
It is a reasonable assumption, yes. So we probably connected all that time without encryption.... Ok, trying to ping TigerVNC developers. Is there a windows client which is known to work with type 18? Thanks.
I think that the TLS security type (18) is rather uncommon, but gtk-vnc supports it. I think that virt-viewer uses gtk-vnc and should work: http://virt-manager.org/download/
*** Bug 731478 has been marked as a duplicate of this bug. ***
Tried to connect with 3 different vnc viewers on windows and all failed for supported encryption. Real, Tight and Tiger for win x86 clients.
*** Bug 726137 has been marked as a duplicate of this bug. ***
*** Bug 732192 has been marked as a duplicate of this bug. ***
David King, It currently fails (gtk-vnc): [IPv4] Got connection from client XYZ.lan other clients: Client Protocol Version 3.7 Advertising security type 18 Client returned security type 18 TLS Handshake failed: The TLS connection was non-properly terminated. Client XYZ.lan gone Statistics: framebuffer updates 0, rectangles 0, bytes 0 The bug is opened at Fedora's bugzilla [1]. If you prefer I can "move" it to Gnome's bugzilla. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1211038
Exactly how many years will it be before the most widely distributed VNC server on enterprise Linux systems once again supports the most widely distributed VNC client on Windows systems? Is back-porting the previous security functionality impossible or something? It seems like this isn't ever going to be addressed, and considering the frequency with which people are attempting to do what this bug describes, it should be much higher on your priority list. Honestly, you shouldn't even have broken this.
@kevin: I think you misunderstood the problem. Vino stopped working with VNC because now it forces encryption by default. It used to work just o ly because (silently) you had an unencrypted connection. The protocol was never here.
I understood perfectly. I think you misunderstood my comment - these two things should work out together of the box, regardless of the justification used for removing the functionality.
Most of the issues comes from the fact the security_type 18 is marked as "historical assignment" in RFC 6143. So when a TCP connection is established in clear, proposing 18 as the only valid security is somewhat against the RFC. Making Vino a custom VNC implementation. There must be a right way to do this ...
Could the right way be to estalished a TLS connection first, and then obay to the protocol rather then using deprecated/historical features ? In this case, we could simply reject non-TLS connection if that's what we want to enforce ?
(In reply to Nicolas Dufresne (stormer) from comment #16) > Could the right way be to estalished a TLS connection first, and then obay > to the protocol rather then using deprecated/historical features ? In this > case, we could simply reject non-TLS connection if that's what we want to > enforce ? Or support the vencrypt security type to negotiate a TLS connection instead of the current (undocumented?) TLS security type? https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst#vencrypt
I just resigned to using unencrypted VNC over an ad-hoc SSH (encrypted) tunnel; and maybe this is the right solution in the end... (composing tools is the unix way, no?). Another solution is using x11vncserver on Linux and SSVNC on windows. Details at http://askubuntu.com/a/408375/16395 But yes, I still think that Windows TightVNC and TigerVNC should work out-of-the box with vino. It's a quite visible problem.
(In reply to Peter Korsgaard from comment #17) > Or support the vencrypt security type to negotiate a TLS connection instead > of the current (undocumented?) TLS security type? > > https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst#vencrypt That could be an option too. A question I don't know the answer is what the other server propose for allowing encrypted connection ? On my side, I'm implementing the undocumented TLS handshake in my client, as it's relatively simple method in fact.
This bug has affected Android VNC clients in an unexpected way. Vino's AnonTLS uses Anonymous Diffie Hellman certificates which do not provide identity verification (unlike x509 certificates). Consequently, while they provide link encryption, they do not guard against man-in-the-middle attacks. Google decided to drop support for these certificates in v6.0+ (API23): https://developer.android.com/reference/javax/net/ssl/SSLEngine.html This has made it impossible to support AnonTLS in Android 6.0+. This bug has been reported to Ubuntu here (for more information): https://bugs.launchpad.net/ubuntu/+source/vino/+bug/1615251 Changing the default to not require encryption is the proper short-term solution. Long-term, implementing VeNCrypt in Vino is the right way to go.
3 1/2 years later, we still have unusable screen-sharing to Windows out of the box even on local networks. Please make it work, with loud warnings about non-encrypted communication if necessary. OTOH, is there *really* no encrypted protocol supported by any widely-available Windows VNC viewer which Vino can use?
Jim: Please provide a patch to make it work if you want to see this fixed. Thanks.
(In reply to André Klapper from comment #22) > Jim: Please provide a patch to make it work if you want to see this fixed. Hrm. I am quite busy supporting my own software, thank you very much. My point is that I gather from above (possibly incorrectly) that the server *could* be made to work, either unencrypted with warnings, or using a publicly documented handshake protocol, but a choice was made and sustained for all this time which has the practical effect of breaking almost all Windows-client users. If you mean to say that vino is no longer supported, so nothing will be fixed, then I understand completely. If that's the case, it would help to be more clear about the situation. Otherwise, I think that having no usable screen-sharing to Windows clients remains a major defect^H^H^H^H^H^H limitation.
@Jim AFAIK vino is in maintenance mode, since it is Xorg only. There is GNOME Remote Desktop for Wayland -- but feature-wise is exactly the same as vino. From what I can gather from my own observations and theories, remote desktop is in stasis until the rest of the graphic stack is mature. Adding my two cents now: IMO asking for the feature will not yield results from the current developers, since they are 100% busy elsewhere. You have four options: 1) submit a patch 2) configure xRDP [1] [out of the scope of this comment] 3) use NoMachine (free for home users but not libre) 4) organize some kind of bounty to get someone else to get it done I might add that GNOME Remote Desktop uses LibVNCServer [2], which seems to be based on the featureful x11vnc (or the other way around, idk) and the rest of Karl Runge stack [3], so creating a patch may be easier than thought. [1] http://xrdp.org/ [2] https://libvnc.github.io/ [3] http://www.karlrunge.com/x11vnc/
Vino is not under active development anymore and unmaintained. Please use gnome-remote-desktop instead. Closing this report as WONTFIX to reflect reality.