Re: [Libvncserver-common] Unknown VeNCrypt authentication scheme from VNC server: 2

[Djuro D. <dju...@gm...>]

Hello,

(at the end of the email you can probably find the most probable reason for
my problems - it appears to be in the server)

I am still mostly "lost" with all of this unfamiliar code, but from what I
see the problem is that ReadVeNCryptSecurityType() receives security type
value "2" which it doesn't support and I have no idea how this could even
be sent from the server (I also looked in the server sources).

Appareantly all the sub authentication values should be equal or bigger
than 256, but this one is for some reason 2... and this is why it is not
accepted in ReadVeNCryptSecurityType(). At least this coresponds to the
debug output that I got from KRDC:

...
krdc(19087)/krdc (VNC backend) VncClientThread::run: ---------------------
trying init ---------------------
krdc(19087)/krdc (VNC backend) VncClientThread::outputHandler: "VNC server
supports protocol version 3.8 (viewer 3.8)"
krdc(19087)/krdc (VNC backend) VncClientThread::outputHandler: "We have 2
security types to read"
krdc(19087)/krdc (VNC backend) VncClientThread::outputHandler: "0) Received
security type 19"
krdc(19087)/krdc (VNC backend) VncClientThread::outputHandler: "Selecting
security type 19 (0/2 in the list)"
krdc(19087)/krdc (VNC backend) VncClientThread::outputHandler: "1) Received
security type 2"
krdc(19087)/krdc (VNC backend) VncClientThread::outputHandler: "Selected
Security Scheme 19"
krdc(19087)/krdc (VNC backend) VncClientThread::outputHandler: "OpenSSL
initialized."
krdc(19087)/krdc (VNC backend) VncClientThread::outputHandler: "Got
VeNCrypt version 0.2 from server."
krdc(19087)/krdc (VNC backend) VncClientThread::outputHandler: "We have 1
security types to read"
krdc(19087)/krdc (VNC backend) VncClientThread::outputHandler: "0) Received
security type 2"
krdc(19087)/krdc (VNC backend) VncClientThread::outputHandler: "Unknown
VeNCrypt authentication scheme from VNC server: 2"
krdc(19087) MainWindow::disconnectHost:
...

Is it possible that for some reason only the LSB part of the auth. code is
received? At least this would then corespond to auth. code 258 which is
"rfbVeNCryptTLSVNC". Would a solution (or at least a workaround) be to
change the received auth. code from 2 to 258?


So I just checked the xorg-x11-Xvnc (my vnc server from an openSUSE repo)
source code and it appears that at first connection it sends this list
(list is read from method Security::GetEnabledSecTypes() ):
- secTypeVeNCrypt (this is value "19")
- all other enabled sec. types (in my case the only other sec. type is "2"
according to the debug output above)


And when the client confirms that it wants to connect with VeNCrypt auth.
code "19" it then sends this list (list is read from method
Security::GetEnabledExtSecTypes() ):
- all other enabled sec. types (exactly the same as above - in my case just
"2")

>From this I would imagine that the Xvnc server has a bug...

I also found this in the man pages for Xvnc:
...
-SecurityTypes sec-types
              Specify which security schemes to use separated by commas.
At present only "None" and "VncAuth" are supported.  The default is
"VncAuth" - note that if you want a server which does not require a
password,  you  must
              set this parameter to "None".
...

I guess this means that it doesn't actually support VeNCrypt auth?

Regards,
Djuro Drljaca


On Mon, Mar 31, 2014 at 9:48 PM, Johannes Schindelin <
Joh...@gm...> wrote:

> Hi Djuro,
>
> On Mon, 31 Mar 2014, Djuro Drljaca wrote:
>
> > I am currently using "vncviewer" from "tightvnc" package on openSUSE and
> > the server that I am connecting to is also from the "tightvnc" package.
> > When Johannes closed the [SourceForge] bug report he invited me to
> > implement this feature myself, but before I can decide if I will really
> > attempt to implement this I would like to get a few answers to my
> > questions:
> >
> > 1) Is it OK if I take this feature from tightvnc and integrate it here?
> > I haven't checked the tightvnc's code so I don't know if it is easier to
> > use this or implement it from scratch, also there might be some
> > licensing issues for your project.
>
> As far as I remember, TightVNC is BSD-licensed. For historical reasons,
> LibVNCServer is GPLv2 licensed, so that would work (the opposite direction
> does not work).
>
> However, I seem to recall that TightVNC's implementation was using C++,
> which might make it a little cumbersome to port the changes required to
> support VeNCrypt.
>
> > 2) Where could I get the documentation for the "VeNCrypt scheme 2"
> > authentication?
>
> The number one go-to document is always:
>
>         http://www.realvnc.com/docs/rfbproto.pdf
>
> > 3) How difficult would it be to implement this?
>
> There is probably some work involved. It is good timing because I am
> actually actively developing some support for VeNCrypt this week, but for
> LibVNCServer (not LibVNCClient). I will be able to answer your question
> more competently in a week from now, I guess.
>
> > And just a little information about myself. I am a C / C++ / C#
> developer,
> > but in the last few years I have worked mostly in C (embedded systems)
> and
> > C# (support PC tools).
>
> That's a good background! Welcome aboard,
> Johannes
>