[PATCH] Implement encryption support for TightVNC

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

[PATCH] Implement encryption support for TightVNC

Martin Koegler
One thing, I'm missing in various VNC implementations is a builtin
encryption. Its a lot easier, if you just have one Executable without
external dependencies like SSH for a tunnel.

Mark McLoughlin created a patchset to encrypt the VNC traffic via GNU
TLS some years ago. Based on these patches, I created a patchset for
RealVNC, which works on all three plattforms (Windows, Unix, Java [via
Sun JSSE]):
https://www.auto.tuwien.ac.at/~mkoegler/index.php/tlsvnc

Based on this, Vencrypt get created, which had a better Windows GUI:
https://sourceforge.net/projects/vencrypt

Now, the free version of RealVNC didn't see any major updates. So I
need to port them to a new plattform. As the new trunk version
(http://vnc-tight.svn.sourceforge.net/viewvc/vnc-tight/trunk/) is
based on RealVNC and is updated, this seems to be a good plattform.

I created some patches, which add encryption via GNU TLS to the trunk version:
http://e9925248.users.sourceforge.net/

The patches do:
* Implement tightvnc Security Type in the C client code
  It does not add/enable any tightvnc specific message/encoding.
* Implement/complete Tunnel selection in C server code and Java Client
* Implement two tunneling modes:
  - TLS: Setup TLS session via Diffie-Hellman - no server authentification
  - X509: TLS session with X509 certifcates

My intention is to get this patches [or something similar] merged, so
could the relevant people please look at them and tell me their
opinion.

I don't currently have a windows system to test, so the windows
enhancements are provided totally untested. To compile the windows client/server,
you need the following:
* add define HAVE_GNUTLS
* compile/link against GNU TLS

For embedding GNU TLS in the tightvnc Windows project, you can look at
the source from https://sourceforge.net/projects/vencrypt.

The unix/java code is very young, so it can still contain some bugs.

mfg Martin Kögler

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
VNC-Tight-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vnc-tight-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Implement encryption support for TightVNC

Adam Tkac
On Tue, Dec 02, 2008 at 06:45:16PM +0100, Martin Koegler wrote:
> One thing, I'm missing in various VNC implementations is a builtin
> encryption. Its a lot easier, if you just have one Executable without
> external dependencies like SSH for a tunnel.

Right you are. I don't think tunelling is good in this situation.

>
> I created some patches, which add encryption via GNU TLS to the trunk version:
> http://e9925248.users.sourceforge.net/
>

Question is if we should rely on gnutls. From long time perspective
better will be use for example NSS library which is FIPS certified.
Certificate handling is far more better in NSS as well.

In my opinion we will base TLS implementation on your patches but use
NSS library instead of gnutls. I'm not sure what other developers think.

Regards, Adam

--
Adam Tkac, Red Hat, Inc.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
VNC-Tight-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vnc-tight-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Implement encryption support for TightVNC

Martin Koegler
On Tue, Dec 02, 2008 at 10:28:23PM +0100, Adam Tkac wrote:
> On Tue, Dec 02, 2008 at 06:45:16PM +0100, Martin Koegler wrote:
> > I created some patches, which add encryption via GNU TLS to the trunk version:
> > http://e9925248.users.sourceforge.net/
> >
>
> Question is if we should rely on gnutls. From long time perspective
> better will be use for example NSS library which is FIPS certified.

What users have access to a "FIPS certified" version of NSS? Where do
we get one from to use it in tightvnc?

The "FIPS certified" thing does not pratically work for tightvnc:

| In addition, for Security Level 1, the operating system must be configured in a single
| operator mode of operation by removing all other user accounts and turning off all remote
| login and access services. If the module is operating at Security Level 2, the environment
| variable NSS_ENABLE_AUDIT must be set to 1 before the application starts.

Quote taken from:
  NSS Cryptographic Module, Version 3.11.4
  FIPS 140-2 Non-Proprietary Security Policy, Level 1 and 2 Validation
  Red Hat, Inc. + Sun Microsystems, Inc.
  http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#814
  http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp814.pdf
  http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#815
  http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp815.pdf

So can we please forget the "FIPS certified" thing and base the
decision on relevant things (API problems, [security] bugs, ...).

> Certificate handling is far more better in NSS as well.
>
> In my opinion we will base TLS implementation on your patches but use
> NSS library instead of gnutls. I'm not sure what other developers think.

On nice feature on Windows, I would like to have, is a vncviewer
executable, which don't need any external dependencies. This means,
that it should be possible to statically link the crypto stuff.

I know, how to do this with gnutls. Its even possible to include it in
the VC project [=> vencrypt], like it is done with zlib. gnutls,
libgpg-error and libgcrypt use automake/autobuild, so it should be no
problem to ship on unix a copy as fallback, like its done with zlib.
This way, we could unconditional support encrypted connections and get
rid of lots of ifdefs.

So, in my option the main pro of gnutls is that it is simple and easy
to integrate.

I admit, that I am not familar with NSS. I looked into the sources.
The first thing, I noticed, is their own build system.

What are the advantages of using NSS for the tightnvc?

mfg Martin Kögler


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
VNC-Tight-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vnc-tight-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Implement encryption support for TightVNC

Pierre Ossman-3
On Wed, 3 Dec 2008 22:18:49 +0100
[hidden email] (Martin Koegler) wrote:

>
> So, in my option the main pro of gnutls is that it is simple and easy
> to integrate.
>
> I admit, that I am not familar with NSS. I looked into the sources.
> The first thing, I noticed, is their own build system.
>
> What are the advantages of using NSS for the tightnvc?
>

I think the biggest advantage is that we avoid forks. Correct me if I'm
wrong here Adam, but Red Hat has an explicit goal of having NSS as the
primary crypto lib. If tight uses another lib, that means that Red Hat
will have to have their own version and although they probably won't do
a full fork, we will have the problems inherent in having two different
versions of the code.

From what I can tell, NSS is also the library with the most complete
PKI support. To properly protect against man in the middle attacks, you
need infrastructure that can verify the host.

That said, NSS is a big pain to work with. Their build system is
horrible and in major need of an overhaul. It is possible to link it
statically though. We do that with the SSH client shipped as part of
the ThinLinc client.

My vote is for NSS. I'd rather fix the superficial problems it has than
go with another lib that has less functionality and divides the
community.

Rgds
--
Pierre Ossman            OpenSource-based Thin Client Technology
System Developer         Telephone: +46-13-21 46 00
Cendio AB                Web: http://www.cendio.com

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
VNC-Tight-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vnc-tight-devel

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Implement encryption support for TightVNC

Adam Tkac
In reply to this post by Martin Koegler
On Wed, Dec 03, 2008 at 10:18:49PM +0100, Martin Koegler wrote:

> On Tue, Dec 02, 2008 at 10:28:23PM +0100, Adam Tkac wrote:
> > On Tue, Dec 02, 2008 at 06:45:16PM +0100, Martin Koegler wrote:
> > > I created some patches, which add encryption via GNU TLS to the trunk version:
> > > http://e9925248.users.sourceforge.net/
> > >
> >
> > Question is if we should rely on gnutls. From long time perspective
> > better will be use for example NSS library which is FIPS certified.
>
> What users have access to a "FIPS certified" version of NSS? Where do
> we get one from to use it in tightvnc?
>
> The "FIPS certified" thing does not pratically work for tightvnc:
>
> | In addition, for Security Level 1, the operating system must be configured in a single
> | operator mode of operation by removing all other user accounts and turning off all remote
> | login and access services. If the module is operating at Security Level 2, the environment
> | variable NSS_ENABLE_AUDIT must be set to 1 before the application starts.
>
> Quote taken from:
>   NSS Cryptographic Module, Version 3.11.4
>   FIPS 140-2 Non-Proprietary Security Policy, Level 1 and 2 Validation
>   Red Hat, Inc. + Sun Microsystems, Inc.
>   http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#814
>   http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp814.pdf
>   http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#815
>   http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp815.pdf
>
> So can we please forget the "FIPS certified" thing and base the
> decision on relevant things (API problems, [security] bugs, ...).

Well, FIPS wasn't the best example why use NSS. I wanted point that
NSS is well maintained, well documented and it is not going to become
dead project when Sun & Red Hat are interested in it, I think.

>
> > Certificate handling is far more better in NSS as well.
> >
> > In my opinion we will base TLS implementation on your patches but use
> > NSS library instead of gnutls. I'm not sure what other developers think.
>
> On nice feature on Windows, I would like to have, is a vncviewer
> executable, which don't need any external dependencies. This means,
> that it should be possible to statically link the crypto stuff.
>
> I know, how to do this with gnutls. Its even possible to include it in
> the VC project [=> vencrypt], like it is done with zlib. gnutls,
> libgpg-error and libgcrypt use automake/autobuild, so it should be no
> problem to ship on unix a copy as fallback, like its done with zlib.
> This way, we could unconditional support encrypted connections and get
> rid of lots of ifdefs.

Static linkage of crypto libraries is evil and I'm against shipping
any crypto library in source. It is nearly always problem because when
security sensitive bug is found in crypto library many users don't
relink their programs.

>
> So, in my option the main pro of gnutls is that it is simple and easy
> to integrate.
>
> I admit, that I am not familar with NSS. I looked into the sources.
> The first thing, I noticed, is their own build system.

Right you are, NSS is more complex than gnutls but it has more
features.

>
> What are the advantages of using NSS for the tightnvc?
>

NSS compatibility with various crypto modules is legendary. If you
have NSS on your system you can simply use external crypto module as
certificate storage and it works. Not sure if it is easy via gnutls.

Adam

--
Adam Tkac, Red Hat, Inc.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
VNC-Tight-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vnc-tight-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Implement encryption support for TightVNC

Adam Tkac
In reply to this post by Pierre Ossman-3
On Thu, Dec 04, 2008 at 09:37:07AM +0100, Pierre Ossman wrote:

> On Wed, 3 Dec 2008 22:18:49 +0100
> [hidden email] (Martin Koegler) wrote:
>
> >
> > So, in my option the main pro of gnutls is that it is simple and easy
> > to integrate.
> >
> > I admit, that I am not familar with NSS. I looked into the sources.
> > The first thing, I noticed, is their own build system.
> >
> > What are the advantages of using NSS for the tightnvc?
> >
>
> I think the biggest advantage is that we avoid forks. Correct me if I'm
> wrong here Adam, but Red Hat has an explicit goal of having NSS as the
> primary crypto lib. If tight uses another lib, that means that Red Hat
> will have to have their own version and although they probably won't do
> a full fork, we will have the problems inherent in having two different
> versions of the code.

Well, I have @redhat address but this is TightVNC-only question. If we
decide that library XYZ is the best one then we will use it, no matter
what any distributor wants.

>
> From what I can tell, NSS is also the library with the most complete
> PKI support. To properly protect against man in the middle attacks, you
> need infrastructure that can verify the host.

Right you are. Without server/client verification you can't speak
about security. But I think it is reachable via gnutls as well.

Adam

--
Adam Tkac, Red Hat, Inc.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
VNC-Tight-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vnc-tight-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Implement encryption support for TightVNC

Constantin Kaplinsky
In reply to this post by Pierre Ossman-3
Hello Pierre,

>>>>> Pierre Ossman wrote:

> My vote is for NSS. I'd rather fix the superficial problems it has than
> go with another lib that has less functionality and divides the
> community.

I'd prefer NSS as well.

--
With Best Wishes,
Constantin


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
VNC-Tight-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vnc-tight-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Implement encryption support for TightVNC

Martin Koegler
In reply to this post by Adam Tkac
The consensus seems to be NSS, so I'll look into porting my patches.

On Thu, Dec 04, 2008 at 01:41:53PM +0100, Adam Tkac wrote:

> On Wed, Dec 03, 2008 at 10:18:49PM +0100, Martin Koegler wrote:
> > On Tue, Dec 02, 2008 at 10:28:23PM +0100, Adam Tkac wrote:
> > > On Tue, Dec 02, 2008 at 06:45:16PM +0100, Martin Koegler wrote:
> > > > I created some patches, which add encryption via GNU TLS to the trunk version:
> > > > http://e9925248.users.sourceforge.net/
> >
> > > Certificate handling is far more better in NSS as well.
> > >
> > > In my opinion we will base TLS implementation on your patches but use
> > > NSS library instead of gnutls. I'm not sure what other developers think.
> >
> > On nice feature on Windows, I would like to have, is a vncviewer
> > executable, which don't need any external dependencies. This means,
> > that it should be possible to statically link the crypto stuff.
> >
> > I know, how to do this with gnutls. Its even possible to include it in
> > the VC project [=> vencrypt], like it is done with zlib. gnutls,
> > libgpg-error and libgcrypt use automake/autobuild, so it should be no
> > problem to ship on unix a copy as fallback, like its done with zlib.
> > This way, we could unconditional support encrypted connections and get
> > rid of lots of ifdefs.
>
> Static linkage of crypto libraries is evil and I'm against shipping
> any crypto library in source. It is nearly always problem because when
> security sensitive bug is found in crypto library many users don't
> relink their programs.

For linux system, I agree with you about static linking, as the
libraries are shipped as part of the distribution and are likely to be
already installed. Only if you work with a system without the
necessary crypto libraries installed and where you can't get them
installed, a statical linked version is acceptable.

For windows, the situation is different. Nowadays, you can expect a
.NET framework, but not NSS or gnutls. Statical linked version are
easier to use for a typical windows user and can be easily copied
around. From the security perspecitve, its does not any harm, as there is
no global copy of the crypto libraries. The libraries of tightvnc will
only be updated by installing the next version of tightvnc.

=> So its a usabiltity issue on windows.

The question about shipping crypto libraries in the source is a
different topic:
* Should the encryption support be only an optional feature or not?
  - If it is optional, we need ifdefs to enable/disable it.
  - If it is not optional, we require a crypto library. Without any
    integrated into the source and build system[1], we require the user
    to prepare additional software, before he can compile tightvnc.

For linux, I don't see any problem to for a user to install any
crypto build files. There are enough GUIs to install the required
distribution packages.

Again, windows is different. Tightvnc is built by MS VC 6 or up [I
failed to build RealVNC with mingw, as it is using some MS specific
constructs]. NSS comes with its own, different build environment:
https://developer.mozilla.org/En/NSS_reference/Building_and_installing_NSS/Build_instructions
To build tightvnc, a user must be able to do both steps and integrate
the result of the NSS build into the tightvnc build system.

=> Who should be able to build tightvnc for windows?

These questions must be answered by the project.

mfg Martin Kögler
[1] For NSS, this will be much more difficult then for gnutls. Therefore
 I would even use the NSS build system on windows.

------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
VNC-Tight-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vnc-tight-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Implement encryption support for TightVNC

Adam Tkac
On Fri, Dec 05, 2008 at 09:27:02AM +0100, Martin Koegler wrote:
> The consensus seems to be NSS, so I'll look into porting my patches.

Please wait for comments from Windows developers. They are currently
doing major changes in Windows version thus I don't know what is their
status for such feature.

Also please add us more time to inspect current version of patches.

Regards, Adam

--
Adam Tkac, Red Hat, Inc.

------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
VNC-Tight-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vnc-tight-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Implement encryption support for TightVNC

Karl J. Runge
In reply to this post by Martin Koegler
On Tue, 2 Dec 2008, [hidden email] (Martin Koegler) wrote:
>
> The patches do:
> * Implement tightvnc Security Type in the C client code
>   It does not add/enable any tightvnc specific message/encoding.
> * Implement/complete Tunnel selection in C server code and Java Client
> * Implement two tunneling modes:
>   - TLS: Setup TLS session via Diffie-Hellman - no server authentification
>   - X509: TLS session with X509 certifcates

I just now realized that these patches do not implement VeNCrypt, but
use the TightVNC security-type mechanism to plumb the TLS tunnel.

I'm confused why TightVNC would implement yet another TLS solution when
it would be interoperable with vinagre/gtk-vnc, vino (small change),
Qemu/Xen, GGI, and others if it implemented VeNCrypt.

There seems to be growing momentum for VeNCrypt; if that's true, it would
be nice not to add to the entropy.  However, once the TLS framework is
in place I guess it might be relatively easy to support both.

Thanks,

Karl


------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
VNC-Tight-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vnc-tight-devel
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] Implement encryption support for TightVNC

Constantin Kaplinsky
In reply to this post by Adam Tkac
>>>>> Adam Tkac wrote:

>> The consensus seems to be NSS, so I'll look into porting my patches.
>
> Please wait for comments from Windows developers. They are currently
> doing major changes in Windows version thus I don't know what is their
> status for such feature.

Well, current work on TightVNC for Windows does not affect the code in
trunk. And actually I cannot guarantee that code in trunk/win will
become "official" TightVNC. Feel free to change and use the code from
svn, but there are no guarantees about protocol compatibility with
future TightVNC stable versions etc.

We are interested in having built-in encryption in TightVNC but we have
not yet decided how it actually should be implemented.

--
With Best Wishes,
Constantin

------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
VNC-Tight-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vnc-tight-devel