VNC accessible from non-linux machines only with encryption disabled

Bug #1281250 reported by Romano Giannetti on 2014-02-17
340
This bug affects 80 people
Affects Status Importance Assigned to Milestone
TigerVNC
New
Unknown
vino
Confirmed
Medium
vino (Fedora)
Unknown
Unknown
vino (Ubuntu)
High
Unassigned
Trusty
High
Unassigned

Bug Description

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?

summary: - VNC accessible for WIndows machine only with encryption disabled
+ VNC accessible for Windows machines only with encryption disabled
Changed in vino (Ubuntu):
importance: Undecided → Low

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in vino (Ubuntu):
status: New → Confirmed
Sebastien Bacher (seb128) wrote :

Thank you for your bug report. Not sure if that's a bug or just increased security config by default. It might mean that you should fix your client to use a secure correction...

Changed in vino (Ubuntu):
status: Confirmed → Triaged
importance: Low → High

I agree that the best possible solution would be for the Windows clients (at least TigerVNC and TightVNC) to catch up. Unfortunately this has not happened; for the time being it would be much better if vino could offer the option to go back to the previous Security Type when the client does not support the new one.

The only solution now is disable the encryption completely; I resorted to a loop back ssh connection so that there is no clear traffic on the wifi, but I still need to do the local step with vino in clear way --- almost safe for me because I do not have other local users, but you never know...

Sebastien Bacher (seb128) wrote :

Did the security level change or was the old default to accept unsecure login (which seems a buggy default)?

I reported the thing to TigerVNC bug tracker too: https://sourceforge.net/p/tigervnc/bug-tracker/148/ let's see if a solution can be found...

Sebastian: no. the default is to use encryption. But after updating vino (do not remember at which point), vino changed the security type to a new one (at least, I think); the connection stopped to work with the error reported above and the only solution to have it back was to disable encryption.

What I *suppose* happened is that the vino server upgraded the encryption algorithm and the clients have still to catch up; the problem is that there seems no way to say vino to use an old encryption --- it just works with the "type 18" or none.

Sampo Savola (samposavola) wrote :

Rmano, I dont think this is a duplicate: https://bugs.launchpad.net/ubuntu/+source/vino/+bug/1307084

If you read my bug raport...I disabled the encryption with dconf trick but still it didnt work from Mac OSX Screen Sharing application. Dconf trick makes other vnc clients work such as TightVNC but only solution for Mac OSX Screen Sharing to work was to build older Vino-server from 13.10.

Sebastien Bacher (seb128) wrote :

@Sampo: ok, unduplicated, please send upstream, we don't have macOS systems to test your specific issue

Sebastien Bacher (seb128) wrote :

The issue you are reporting is an upstream one and it would be nice if somebody having it could send the bug to the developers of the software by following the instructions at https://wiki.ubuntu.com/Bugs/Upstream/GNOME. If you have done so, please tell us the number of the upstream bug (or the link), so we can add a bugwatch that will inform us about its status. Thanks in advance.

Ok, I have reported it upstream at

 https://bugzilla.gnome.org/show_bug.cgi?id=728267

--- but I am unable to add it to the bug. I used to choose älso affect distribution"and simply paste the URL, but now I have an error (says I can't add another bug to the same distribution and in the dsitribution lists there is no "gnome upstream to choose"). How am I supposed to add the upstream bug?

Can please people with the problem state their version? Mine is

[:~] 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

Anyone with stock 3.8 version?

Sebastien Bacher (seb128) wrote :

Upstream comment

"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."

Changed in vino:
importance: Unknown → Medium
status: Unknown → Confirmed

Upstream comment:

"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/
"

so basically the problem is that vino is using an encryption type which is supported only by few clients. The optimal solution would be to help vino developers to add a more common encryption type; for the time being, I will test the suggested viewer and comment.

Well, downloaded it (virt-viewer, I mean). Tried to connect to a remote machine but no dice --- it just show a window, asking for a connection URI, I tried 200 combinations... No documentation handy available either. Seems to be thought just for managing virtual machines, so it doesn't seem a general VNC viewer tool.

So I think that the only option now is

a) having a VNC with almost no interoperability with Windows

or

b) re-defaulting to no encryption

Really, I do not know which one of the two options is the worst one.

Holger Mauermann (mauermann) wrote :

This doesn't affect only Windows, but Android too. I tried two different apps ("VNC Viewer" from RealVNC Limited and "Jump Desktop" from Phase Five Systems), but since upgrading my Ubuntu Desktop to Trusty both fail with error messages related to incompatible security types.

@Holger: yes --- I just noticed it too.

I humbly suggest that Canonical or Redhat help the vino developers to add a more common encryption type to the vino server. It is the default (and the facto only) remote vnc server in our system, and in its current state forces everyone to connect **in clear** on the local network. All what you type is sent as is.

I have worked around it wrapping the thing in a SSH tunnel, but still, it's sensible to local attacks and I think it's not a solution for the average user.

@Sebastian, I am not sure if this is a security thing --- after all, before the switch, all the connections were silently made without encryption, but it's scary nevertheless --- sniffing for traffic on port 5900 is easy enough.

nitrogen dream (nitrogendream) wrote :

Guys,

The problem is simple.
If you take a Wireshark trace you immediately see the issue.
You will have to filter on VNC.
The supported security type which is given for 14.04 is "type 18, TLS".
For 13.10 we see two types, "type 18, TLS" and "type 2, VNC".

The "type 2, VNC" is used by your VNC viewer.
So adding type 2 in the proposed supported security types will solve this bug.

Plurtu (plurtu) wrote :

Enhanced TightVNC Viewer (SSVNC) works with vino's ANONTLS encryption on Windows.

http://www.karlrunge.com/x11vnc/ssvnc.html

Don't expect to connect in a hurry though.

@nitrogen dream: reading here: https://sourceforge.net/p/tigervnc/code/HEAD/tree/rfbproto/rfbproto.rst#vnc-authentication, with type 2 the only thing that is encrypted is the VNC password, which is, honestly, my least worry. All the keystrokes in the session (including your bank password) is then sent unencrypted on the local wire.

Will check SSVNC; but this is similar to what I am doing now, having a ssh tunnel in the middle.

But again, the problem is in vino, which is offering as encrypted transport one that nobody uses --- and that force you to go thru hoops to have an almost safe connection.

summary: - VNC accessible for Windows machines only with encryption disabled
+ VNC accessible from non-linux machines only with encryption disabled

SSVNC works, although is quite slow with vino. Using x11vnc as server with -ssl options give a reasonable speed.

Apologises, I am not a super expert but I suffer this VNC BUG after Ubuntu TLS 14.04 upgrade.

Unfortunately to me does not work dconf > desktop > gnome > remote-access > enabled - uncheck
 (it is unchecked but VNC continue do not work at Ubuntu reboot)

Only to set 'gsettings set org.gnome.Vino require-encryption false' manually works

is there any workaround to disable encription and remain disabled at reboot until this BUG is not fixed ?

Many Thanks

Vladimir Plotnikov (monomakh) wrote :

I am confirm, that vino doesn't work after upgrade to 14.04 and gsettings set org.gnome.Vino require-encryption false doesnt helps to start vino server.

try in this way:

$ pkill vino
$ export DISPLAY=:0.0
$ /usr/lib/vino/vino-server &
$ gsettings set org.gnome.Vino require-encryption false

VNCclient you have to choose encryption off

Kurt M. Sanger (ksanger) wrote :

I too am having trouble connecting to Ubuntu 14.04 LTS, however we are trying to connect using Ubuntu 12.04 LTS. We've tried encryption off. We've tried Remina Remote Desktop Client, and Gtk Vnc Viewer. Bot VNC applications are able to login to the 14.04 box, however neither one of them will control anything. The remote screen does not update. Windows are imovable. Mouse clicks do not appear to work.

When using Remina Remote Desktop Client and encryption off you can see that sometimes the 14.04 screen has changed due to actions on the 12.04 remote session. For instance cntrl alt T opened a terminal session. However the remote screen on the 12.04 remote session does not update and the new terminal sessions were not shown remotely.

On the 14.04 box I have allow others to control your desktop checked through desktop sharing. I also have encryption off. We have tried killing vino, setting DISPLAY, restarting vino-server, and setting encryption off using gsettings. Also view-only is false.

Kurt M. Sanger (ksanger) wrote :

Today we tried the command gsettings set org.gnome.Vino disable-xdamage true, which also did not work. Then we wiped the hard drive and loaded Ubuntu 12.04 LTS. We could not remote into 12.04 LTS from 12.04 LTS using either Remmina Remote Desktop nor Gtk VNC Viewer until we first logged into the remote machine using 2D mode. Then the remote session updated the screen and enabled us to see our controlling of the remote PC.

Interestingly we then logged off and logged back into the remote PC in 3D mode and the remote connection still worked. Finally we rebooted the remote PC, logged in under 3D mode, and the remote connection still works. I have no idea what is different but logging in one time under 2D mode set something up correctly. Wish I had tried that on 14.04, however I'm not going back soon. Hopefully this will help you guys figure this out.

Currently the command gsettings get org.gnome.Vino disable-xdamage returns false on the remote PC.

Wes Garner (wesgarner) wrote :

FYI Solution for Android users - use bVNC Free
It accepts this encryption type

Rudolf Reuter (reuterr) wrote :

In case you boot with an USB-stick, it may be very difficult to get VNC running.

A quick workaround in the terminal, to make it work:
$ gsettings set org.gnome.Vino enabled true
$ gsettings set org.gnome.Vino require-encryption false

Hrotkó Gábor (roti-al) wrote :

On windows, I use SSVNC to connect to vino-server, and it works great.

John Moser (nigelenki) wrote :

It also resets the configuration every time you upgrade Ubuntu, so the work-around must be re-applied. Breaking a system's custom configuration when upgrading is probably bad juju.

Peter Funk (pf-artcom-gmbh) wrote :

Question: How can I apply "gsettings set org.gnome.Vino require-encryption false" in a ssh-session from remote?

Jamshid Afshar (jafshar) wrote :

Even after disabling encryption I cannot get OS X El Capitan to connect -- it asks for a password then spins. Using the Mac app Chicken of the VNC does work, though.

Iordan Iordanov (iiordanov) wrote :

The upstream bug was reported about 2.5 years ago. It certainly looks like the developers of Vino are not going to change the default to not require encryption. Would it be possible to change the default for Ubuntu to not require encryption at least?

Varstamni Q (varstamni) wrote :

Iordane (Dancho), it is not a bug at all. It is inconvenient for me too, but they are the developers of vnc clients for windows who do not do the appropriate thing (add TLS support or so). To have default behavior not to require encryption is a very bad idea basically. And you can disable it by hand at any time.

Using a protocol that does not verify the identity of the server in
any way (AnonTLS that uses Anonymous Diffie Hellman ciphers) can be as
good as no encryption or worse, as it gives users a false sense of
security.

On Sun, Mar 5, 2017 at 11:25 AM, Varstamni Q <email address hidden> wrote:
> Iordane (Dancho), it is not a bug at all. It is inconvenient for me too,
> but they are the developers of vnc clients for windows who do not do the
> appropriate thing (add TLS support or so). To have default behavior not
> to require encryption is a very bad idea basically. And you can disable
> it by hand at any time.
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1615251).
> https://bugs.launchpad.net/bugs/1281250
>
> Title:
> VNC accessible from non-linux machines only with encryption disabled
>
> Status in vino:
> Confirmed
> Status in vino package in Ubuntu:
> Triaged
> Status in vino source package in Trusty:
> Triaged
> Status in vino package in Fedora:
> Unknown
>
> Bug description:
> 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?
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/vino/+bug/1281250/+subscriptions

--
The conscious mind has only one thread of execution.

Changed in tigervnc:
status: Unknown → New
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.