After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 728267 - Support new VNC security types
Support new VNC security types
Product: vino
Classification: Applications
Component: Server
Other Linux
: Normal normal
: ---
Assigned To: Vino Maintainer(s)
Vino Maintainer(s)
: 726137 731478 732192 (view as bug list)
Depends on:
Reported: 2014-04-15 14:26 UTC by Romano Giannetti
Modified: 2020-11-12 12:24 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Romano Giannetti 2014-04-15 14:26:17 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:

And on Ubuntu/Launchpad: 

I mentioned the problem in TigerVNC tracking system:
Comment 1 David King 2014-04-15 14:45:28 UTC
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:

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.
Comment 2 Romano Giannetti 2014-04-15 14:52:54 UTC
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 
  Installed: 3.10.0-0ubuntu1~saucy1
  Candidate: 3.10.0-0ubuntu1~saucy1
  Version table:
 *** 3.10.0-0ubuntu1~saucy1 0
        500 saucy/main i386 Packages
        100 /var/lib/dpkg/status
     3.6.2-0ubuntu5 0
        500 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.
Comment 3 David King 2014-04-15 15:02:59 UTC
I guess that the problem occurs after the default was changed to require encryption:

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:

I will not have time to add the security types in the near future.
Comment 4 David King 2014-04-15 15:04:20 UTC
(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.
Comment 5 Romano Giannetti 2014-04-15 15:08:50 UTC
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? 

Comment 6 David King 2014-04-15 15:23:47 UTC
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:
Comment 7 David King 2014-06-10 19:17:59 UTC
*** Bug 731478 has been marked as a duplicate of this bug. ***
Comment 8 Brook Harty 2014-06-15 15:42:15 UTC
Tried to connect with 3 different vnc viewers on windows and all failed for supported encryption.  Real, Tight and Tiger for win x86 clients.
Comment 9 David King 2014-06-22 14:45:24 UTC
*** Bug 726137 has been marked as a duplicate of this bug. ***
Comment 10 David King 2014-06-24 22:38:21 UTC
*** Bug 732192 has been marked as a duplicate of this bug. ***
Comment 11 Pedro F. 2015-04-12 12:42:02 UTC
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
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.

Comment 12 Kevin M. Kelly 2015-06-13 00:09:52 UTC
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.
Comment 13 Romano Giannetti 2015-06-13 06:51:41 UTC
@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.
Comment 14 Kevin M. Kelly 2015-06-13 16:57:06 UTC
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.
Comment 15 Nicolas Dufresne (ndufresne) 2016-03-14 22:19:50 UTC
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 ...
Comment 16 Nicolas Dufresne (ndufresne) 2016-03-14 22:22:23 UTC
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 ?
Comment 17 Peter Korsgaard 2016-03-16 11:32:21 UTC
(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?
Comment 18 Romano Giannetti 2016-03-16 11:54:06 UTC
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 

But yes, I still think that Windows TightVNC and TigerVNC should work out-of-the box with vino. It's a quite visible problem.
Comment 19 Nicolas Dufresne (ndufresne) 2016-03-16 18:27:03 UTC
(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?

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.
Comment 20 iiordanov 2016-08-23 04:38:20 UTC
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):

This has made it impossible to support AnonTLS in Android 6.0+.

This bug has been reported to Ubuntu here (for more information):

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.
Comment 21 Jim Avera 2020-01-12 21:21:20 UTC
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?
Comment 22 André Klapper 2020-05-18 12:09:32 UTC
Jim: Please provide a patch to make it work if you want to see this fixed. Thanks.
Comment 23 Jim Avera 2020-05-27 05:29:44 UTC
(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.
Comment 24 Pedro F. 2020-05-28 09:57:28 UTC

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.

Comment 25 André Klapper 2020-11-12 12:24:25 UTC
Vino is not under active development anymore and unmaintained.

Please use gnome-remote-desktop instead.

Closing this report as WONTFIX to reflect reality.