Re: java viewer source

[Dale S. <ds...@ll...>]

Constantin Kaplinsky wrote:

>>>>>> Dale Southard wrote:
> 
>> Adding to the confusion.  I have an independently developed SSL patch
>> for the tightvnc java client but never committed upstream.  At the
>> time (May 06), Constantin was busy with the codebase merge, so it was
>> a bad time to add features.  Then I got busy with other things and
>> never went back to merge.
> 
> Well, I think the Java viewer code will not ever be merged with VNC4
> Java code, so actually it might be a good idea to incorporate SSL into
> the current version.
> 
> It that possible that we could join our efforts and adopt existing SSL
> tunneling implementations into the TightVNC Viewer? First of all, it
> could be great to include some _minimal_ set of changes that does not
> change any defaults, does not have any GUI etc. In other words,
> something that I will easily understand. :)

Speaking for my SSL mod, the SSL patches to the VNC client were around
100 lines total.  They added basic SSL functionality and two parameters
("useSSL" to turn on SSL for the connection, and "sslTrustAll" to
suppress checking of the certificate trust chain for people using
self-signed certs).  No GUI, etc.

Note that I used the Java 1.2 SSL implementation, so the resulting
client needed to be compiled with at least java 1.2.  For our planned
use, this is a fair trade-off vs re-implementing SSL under 1.1.


> And let me ask a few questions:
> 
>   (1) What are the requirements on the server side? Are modifications
>       required in server code, or maybe some stand-alone tunneling
>       program can be used instead?

Again speaking for myself:

For testing, running the server though stunnel is sufficient.  I can
post instructions for setting this up if anyone cares.

Our final goal is deploying a distributed renderserver that handles both
X11 and OpenGL.  So, for the final deployment, the server-side SSL will
be integrated into the program (vncproxy) that composites the X11 rfb
traffic and the OpenGL rfb traffic.  So, for OUR use, no server-side
modifications to VNC-tight are required.


>   (2) What are the primary differences between the existing
>       implementations?

Speaking for myself:

 - My SSL patches depend on java 1.2 or better.

 - My SSL patches do not use the existing socket factory hook.  I think
   it could be done, but was more work and it complicated handling the
   SSL-specific setup somewhat.  [Remember that what I have was a proof-
   of-concept for SSL, the main body of work was in the GL/X11
   compositing stuff.]

   For upstream commit, this would probably need to be looked at again
   and weighed against further SSL requirements.


-- 
/*  Dale Southard Jr.   ds...@ll...  925-422-1463  f:422-9429
 *  Computer Scientist, Advanced Simulation and Computing Program
 *  Lawrence Livermore National Lab, L-556,  Livermore, CA  94551
 */