Thread: [rfbhackers] is anybody working on sercureVNC?

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

please cc to my private mail address, because i'm not subribed to the 
list (seems the project is dead)

I've fallen off the edge of the planet. 

Anyone who wants to take it over, feel free to do so.

Andrew

-----Original Message-----
From: sec...@li...
[mailto:sec...@li...] On Behalf Of
oliver thuns
Sent: Monday, 7 April 2003 1:05 AM
To: sec...@li...
Subject: [rfbhackers] is anybody working on sercureVNC?

please cc to my private mail address, because i'm not subribed to the 
list (seems the project is dead)

-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
Securevnc-rfbhackers mailing list
Sec...@li...
https://lists.sourceforge.net/lists/listinfo/securevnc-rfbhackers

On Mon, 2003-04-07 at 01:28, Andrew van der Stock wrote:
> I've fallen off the edge of the planet. 
> 
> Anyone who wants to take it over, feel free to do so.
> 

I'd be interested to contribute. I've developed for a customer a "RFB
over SSL" solution with a (somewhat - needs improvement) pluggable
authentication mechanism.

Currently it does X.509 certificate auth and "regular" VNC auth. Also,
I've extenden initial RFB client/server handshake so that the authtype
could be negotiated (and then accepted or not by either party depending
on configurable policies).

Something like a basis is laid, but I'd need further contributors to
make it generally usable.

CU, JOe

On Monday 07 April 2003 12:19, Joe Ammann wrote:
> Currently it does X.509 certificate auth and "regular" VNC auth. Also,
> I've extenden initial RFB client/server handshake so that the authtype
> could be negotiated (and then accepted or not by either party depending
> on configurable policies).

Do you have any code/documentation for this? That would be great, since 
exactly this is on my feature list for KDE's Desktop Sharing.

bye...

On Mon, 2003-04-07 at 19:35, Tim Jansen wrote:
> On Monday 07 April 2003 12:19, Joe Ammann wrote:
> > Currently it does X.509 certificate auth and "regular" VNC auth. Also,
> > I've extenden initial RFB client/server handshake so that the authtype
> > could be negotiated (and then accepted or not by either party depending
> > on configurable policies).
> 
> Do you have any code/documentation for this? That would be great, since 
> exactly this is on my feature list for KDE's Desktop Sharing.

Yes. Unfinished, unclean, and mostly Windows code (that was what my
customer wanted). It's based on the TightVNC source, but the part with
changes is just about the same in any VNC variant.

I guess I can grab together my bits tomorrow. I'd be grateful to be able
to discuss this with people, because I feel somewhat "unreflected" until
now.....

I'll have to do some porting to Linux/Solaris anyway, and that seems
also to be a very nice opportunity to dive into the KDE X.509 handling
stuff. I presume you're talking about something like integration with
the Sphinx framework, aren't you?

CU, Joe

On Monday 07 April 2003 22:15, Joe Ammann wrote:
> I'll have to do some porting to Linux/Solaris anyway, and that seems
> also to be a very nice opportunity to dive into the KDE X.509 handling
> stuff. I presume you're talking about something like integration with
> the Sphinx framework, aren't you?

No, the Sphinx framework is only for groupware. Desktop Sharing allows a 
administrator to join a user's desktop using VNC. For this use case VNC's 
password authentication is very bad. The Desktop Sharing server runs with 
user permissions. Thus every user can replace the original server with a 
trojan horse that captures the administrators password (or at least gets the 
right token for a single challenge-response) and use it to access somebody 
else's desktop. The other problem is that it would be desirable if 
administrators could authenticate using their regular account, not with a 
password that is shared among administrators.

So the part that I am most interested in is the handshake to negotiate the 
authentication. My primary focus is Kerberos, as it allows administrators to 
authenticate using their regular accounts even on an untrusted machine. 
That's why I have planned to extend the protocol with a SASL mechanism. I did 
not start coding on this. The timeframe is KDE 3.2, which will probably be 
released in late summer or fall, but there is no schedule yet. 

Authentication using public-key certificates would be a bonus that I have also 
considered (as a solution for small companies and home users who don't have 
Kerberos servers), but not for the next KDE version. 
KDE has KSSL which can be used for managing certicficates and other things, 
but I am not familar with it.

bye...

Hello Tim, Joe,

>>>>> "TJ" == Tim Jansen <ml...@tj...> writes:

>> Currently it does X.509 certificate auth and "regular" VNC auth. 
>> Also, I've extenden initial RFB client/server handshake so that the
>> authtype could be negotiated (and then accepted or not by either
>> party depending on configurable policies).

TJ> Do you have any code/documentation for this? That would be great,
TJ> since exactly this is on my feature list for KDE's Desktop
TJ> Sharing.

And in my feature list (for TightVNC), too. :-)

I've started to work on OpenSSL integration, however, I'm rather
interested in encryption than in certificate-based authentication.

By the way, I also have implemented protocol extensions to negotiate
protocol options such as tunneling/encryption methods, additional
authentication schemes, non-standard normal messages and extra
encodings. The sources are available in the CVS, in both Unix and
Win32 parts.

Joe, could you please send me your changes? Sinse I've already
implemented a subset of similar functionality, I won't include your
changes as is, but I think your work can save some time and prevent
some duplication of efforts.

-- 
With Best Wishes,
Constantin

On Wed, 2003-04-09 at 18:37, Constantin Kaplinsky wrote:
> Hello Tim, Joe,
> 
> >>>>> "TJ" == Tim Jansen <ml...@tj...> writes:
> 
> >> Currently it does X.509 certificate auth and "regular" VNC auth. 
> >> Also, I've extenden initial RFB client/server handshake so that the
> >> authtype could be negotiated (and then accepted or not by either
> >> party depending on configurable policies).
> 
> TJ> Do you have any code/documentation for this? That would be great,
> TJ> since exactly this is on my feature list for KDE's Desktop
> TJ> Sharing.
> 
> And in my feature list (for TightVNC), too. :-)
> 
> I've started to work on OpenSSL integration, however, I'm rather
> interested in encryption than in certificate-based authentication.

I've also implemented this in 2 ways:

1) Just use SSL with anonymous DiffieHellman Keyexchange to get
encryption

2) My "private" extension of this also does cert base authentication.

> By the way, I also have implemented protocol extensions to negotiate
> protocol options such as tunneling/encryption methods, additional
> authentication schemes, non-standard normal messages and extra
> encodings. The sources are available in the CVS, in both Unix and
> Win32 parts.

Probably much the same I did :-) I'll check that out. Probably, I can
base my future release on this.

> Joe, could you please send me your changes? Sinse I've already
> implemented a subset of similar functionality, I won't include your
> changes as is, but I think your work can save some time and prevent
> some duplication of efforts.

I have put up my changes (Win only) to http://www.pyx.ch/joe/vnc/. It's
quite old and not tidied up.

CU, Joe

On Wed, 2003-04-09 at 18:37, Constantin Kaplinsky wrote:

Hi Const

> TJ> Do you have any code/documentation for this? That would be great,
> TJ> since exactly this is on my feature list for KDE's Desktop
> TJ> Sharing.
> 
> And in my feature list (for TightVNC), too. :-)
> 
> I've started to work on OpenSSL integration, however, I'm rather
> interested in encryption than in certificate-based authentication.
> 
> By the way, I also have implemented protocol extensions to negotiate
> protocol options such as tunneling/encryption methods, additional
> authentication schemes, non-standard normal messages and extra
> encodings. The sources are available in the CVS, in both Unix and
> Win32 parts.

Just looked at your changes in CVS. I could see that the protocol
extension are much more general than mine, and I can easily integrate my
requirements into this.

Am I right in finding that your CVS does not yet contain any actual
OpenSSL integration? If yes, would my changes maybe fit your
requirements?

As said in my previous mail, my "public" changes to not contain (yet)
any certificate stuff. Just using anon DH keyexchange (ADH-RC4-MD5) then
provides "pure" encryption, without any cert stuff. But that of course
also means that they don't provide any means against man-in-the-middle
attacks. If you really decide to go down this way, we might want to
implement something like the "host key feature" of SSH to reduce the
need for trust to the very first connection establishment. Of course,
this then raises questions like where to store the known server keys
etc.

Anyway, you might find it helpful looking into my sources. Although they
are based against Tight 1.2.6 (with some non-encrytpion related
changes), they should be easily integratable.

I implemented encryption by subclassing the connection classes on both
client and server side. This allowed me to keep encryption related code
in one .h/.cpp file on each client and server. Also, I '#ifdef OPENSSL'
all other required changes (in some places, they were needed). Forget
about the '#ifdef UBS' stuff, those are really related to cert auth
stuff (or other weird things).

Also, I had to make some member function virtual/protected to be able to
override them in the subclasses.

CU, Joe