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.
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: /bugs.launchpad .net/bugs/ 1281250 /bugs.launchpad .net/vino/ +bug/1281250/ +subscriptions
> 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:/
>
> 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:/
--
The conscious mind has only one thread of execution.