|
From: oliver t. <sm...@gm...> - 2003-04-06 15:05:54
|
please cc to my private mail address, because i'm not subribed to the list (seems the project is dead) |
|
From: Andrew v. d. S. <aj...@gr...> - 2003-04-06 23:28:42
|
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 |
|
From: Joe A. <jo...@py...> - 2003-04-07 10:19:58
|
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 |
|
From: Tim J. <ml...@tj...> - 2003-04-07 17:34:52
|
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... |
|
From: Joe A. <jo...@py...> - 2003-04-07 20:16:45
|
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 |
|
From: Tim J. <ml...@tj...> - 2003-04-07 22:17:32
|
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... |
|
From: Constantin K. <co...@ce...> - 2003-04-09 16:39:34
|
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 |
|
From: Joe A. <jo...@py...> - 2003-04-11 13:55:20
|
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 |
|
From: Joe A. <jo...@py...> - 2003-04-11 14:27:17
|
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 |