java viewer source

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

Re: java viewer source

Dale Southard
Constantin Kaplinsky wrote:
> Hello Dale,
>
>>>>>> Dale Southard wrote:

>> For testing, running the server though stunnel is sufficient.  I can
>> post instructions for setting this up if anyone cares.
>
> Yes, I would appreciate if you could send the instructions.

To run SSL tunnel a vnc server:

1) Get a server certificate.  If you don't have a way to get an official
    certificate you can build a self-signed one like so if you have
    openssl available:

      openssl dhparam 1024 -out dh1024.pem
      openssl genrsa -aes256 1024 > host.key  (password is "password")
      openssl req -new -x509 -nodes -sha1 -days 365 -key host.key \
               > host.cert
      cat host.cert host.key > server.pem

2) Create an stunnel4 config file ("stunnel.conf"):
      cert = /path/to/server.pem
      foreground = yes
      pid =
      [vnc]
      accept = 5701
      connect = 5901

3) start the vnc server (the example assumes it's bound to port 5901)

4) start stunnel (which will prompt you for the password to the
    server.pem that you set above):
      stunnel4 stunnel.conf

You should now have regular cleartext vnc on port 5901 and SSL-armored
vnc on 5701.  If you're using this for more than testing, you probably
want to bind the non-SSL vnc server to localhost if the server supports
it (so that users can't connect to the non-encrypted VNC port).

5) connect to with your ssl vnc client.  Note that if you're using
    a self-signed cert and a java client, the default trust policy
    will reject the server since java can't walk the trust chain
    back to a certificate authority.  You have three options:

    A) Get a real certificate. These are free for personal use from
       a couple sites.

    B) Let java trust your self-signed certificate.  You can either
       bury it in the code like n0g0013 did, or you can just import it
       into a java keystore like this:

         keytool -import -alias "whatever" -file host.cert \
                 -keystore truststore

       Then point the JVM at that keystore when you start the client
       using this flag: java -Djavax.net.ssl.trustStore=truststore

       Note that, in either case, using the client as an web applet
       means you're not as well protected from man in the middle
       attacks.

    C) Have your client build and use an X509TrustManager that trusts
       everything.  Basically the same security issue as b, but also
       applies when running as an application.

My patch did A by default and had a flag that allowed the user to do C
if he/she wanted.  The B option can be done without any code by using
keytool and the command-line flag.


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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.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: java viewer source

ttw+vnc
On 31.10-09:40, Dale Southard wrote:
[ ... ]

>     B) Let java trust your self-signed certificate.  You can either
>        bury it in the code like n0g0013 did, or you can just import it
>        into a java keystore like this:
>
>          keytool -import -alias "whatever" -file host.cert \
>                  -keystore truststore
>
>        Then point the JVM at that keystore when you start the client
>        using this flag: java -Djavax.net.ssl.trustStore=truststore
>
>        Note that, in either case, using the client as an web applet
>        means you're not as well protected from man in the middle
>        attacks.

the applet issue is precisely the situation my hack intends to secure.
it should be secure against MTM attacks (assuming the webserver
delivering the code is not susceptible to them).  are you thinking
that i've missed something here?

>     C) Have your client build and use an X509TrustManager that trusts
>        everything.  Basically the same security issue as b, but also
>        applies when running as an application.

this option does not offer the same security as 'b'.  in 'b' a user
must manually import a known certificate effectively marking it as
trusted.  this is a world away from "trusts everything".  scenario
'c' is very susceptible to MTM attack unless you implement a dialog
like karl did (then it's only easy to perform, not automatic ;-).

i think you've also muddled your use of 'application' and 'applet'
in the above scenario.  i believe you meant to say "also works in
applet mode", since 'b' does not work in an applet (well, my hack
should but that's just a hack, not a solution).

--
        t
 t
                 w

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.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: java viewer source

Dale Southard
n0g0013 wrote:

> On 31.10-09:40, Dale Southard wrote:
> [ ... ]
>>     B) Let java trust your self-signed certificate.  You can either
>>        bury it in the code like n0g0013 did, or you can just import it
>>        into a java keystore like this:
>>
>>          keytool -import -alias "whatever" -file host.cert \
>>                  -keystore truststore
>>
>>        Then point the JVM at that keystore when you start the client
>>        using this flag: java -Djavax.net.ssl.trustStore=truststore
>>
>>        Note that, in either case, using the client as an web applet
>>        means you're not as well protected from man in the middle
>>        attacks.
>
> the applet issue is precisely the situation my hack intends to secure.
> it should be secure against MTM attacks (assuming the webserver
> delivering the code is not susceptible to them).  are you thinking
> that i've missed something here?

Yup.  You are making the assumption that you're actually getting the
applet that you put on the server.  Transfer of the applet is happening
over non-secured http.  The MTM can just substitute his/her own applet
with their own cert.

If you're running as an application, it's OK (assuming that the user has
an authentic cert).

Or maybe I'm mis-reading your patch or your intentions?


>>     C) Have your client build and use an X509TrustManager that trusts
>>        everything.  Basically the same security issue as b, but also
>>        applies when running as an application.
>
> this option does not offer the same security as 'b'.  in 'b' a user
> must manually import a known certificate effectively marking it as
> trusted.

If you're running "B" as an applet, the user is implicitly trusting
whatever cert or CA you compiled in.  If your running "C" the user is
explictly saying that he/she is trusting whatever cert the server gives out.

The phrase "manually import a known certificate effectively marking it
as trusted" is probably what we're disagreeing on.  Your patch appears
to compile the CA into the binary.  The user isn't "manually" doing
anything and has no way to know what he she is trusting.



> this is a world away from "trusts everything".  scenario
> 'c' is very susceptible to MTM attack unless you implement a dialog
> like karl did (then it's only easy to perform, not automatic ;-).

I think I'm misunderstanding what you're proposing, or you're focusing
too much on the SSL stuff and not the whole picture.  If you're handing
the user a self-signed cert CA over http and saying "trust this", you're
outside of the protection provided by X509.  If you're burying it in the
client by compiling in the CA, the users doing this implicitly.

I'm making the user say "trusting all hosts", which is of course *worse*
but they have to say it explicitly.


> i think you've also muddled your use of 'application' and 'applet'
> in the above scenario.  i believe you meant to say "also works in
> applet mode", since 'b' does not work in an applet (well, my hack
> should but that's just a hack, not a solution).

If you do "B" in a way that doesn't support applets (forcing the user to
manually import a cert known to be authentic), then you're correct.

I was assuming, looking at your hack, that you were also trying to
support use as an applet.  In that mode, the cert isn't buying you
anything since the user is implicitly trusting something that came over
a non-secured channel.  You're just moving the MTM attack point from the
rfb protocol to the http one.

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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.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: java viewer source

ttw+vnc
On 31.10-13:30, Dale Southard wrote:
[ ... ]
> > the applet issue is precisely the situation my hack intends to secure.
> > it should be secure against MTM attacks (assuming the webserver
> > delivering the code is not susceptible to them).  are you thinking
> > that i've missed something here?
>
> Yup.  You are making the assumption that you're actually getting the
> applet that you put on the server.  Transfer of the applet is happening
> over non-secured http.  The MTM can just substitute his/her own applet
> with their own cert.
[ ... ]
> Or maybe I'm mis-reading your patch or your intentions?

no, we're on the same page.

        <quote>assuming the webserver delivering the code is not
                susceptible to them</quote>

and good note for other to watch out for.

--
        t
 t
                 w

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.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: java viewer source

ttw+vnc
On 01.11-12:42, n0g0013 wrote:

> On 31.10-13:30, Dale Southard wrote:
> [ ... ]
> > > the applet issue is precisely the situation my hack intends to secure.
> > > it should be secure against MTM attacks (assuming the webserver
> > > delivering the code is not susceptible to them).  are you thinking
> > > that i've missed something here?
> >
> > Yup.  You are making the assumption that you're actually getting the
> > applet that you put on the server.  Transfer of the applet is happening
> > over non-secured http.  The MTM can just substitute his/her own applet
> > with their own cert.
> [ ... ]
> no, we're on the same page.
[ ... ]
> and good note for other to watch out for.

n.b: you can/will need to secure the server delivering the code if
you wish any applet to be secure

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.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: java viewer source

Dale Southard
In reply to this post by ttw+vnc
n0g0013 wrote:

> On 31.10-13:30, Dale Southard wrote:
> [ ... ]
>>> the applet issue is precisely the situation my hack intends to secure.
>>> it should be secure against MTM attacks (assuming the webserver
>>> delivering the code is not susceptible to them).  are you thinking
>>> that i've missed something here?
>> Yup.  You are making the assumption that you're actually getting the
>> applet that you put on the server.  Transfer of the applet is happening
>> over non-secured http.  The MTM can just substitute his/her own applet
>> with their own cert.
> [ ... ]
>> Or maybe I'm mis-reading your patch or your intentions?
>
> no, we're on the same page.
>
> <quote>assuming the webserver delivering the code is not
> susceptible to them</quote>
>
> and good note for other to watch out for.


To summarize what n0g0013 were discussing for the list:


When running as an applet, there's really no way to securely
authenticate the server unless the applet was sent over SSL or another
secure link.  So my confusion looking at the patches was "why embed a CA
cert that can't be trusted".  Doing so doesn't solve the problem, it
just moves it.  So I (wrongly) it was an end-run around self-signed
certs rather than just a way to distribute a cert over an already secure
channel.

As an application, embedding works fine. Just copy the viewer to a flash
drive or CDROM and everything's peachy.  Same for using a trust store.



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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.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: java viewer source

ttw+vnc
On 01.11-10:54, Dale Southard wrote:
[ ... ]
> As an application, embedding works fine. Just copy the viewer to a flash
> drive or CDROM and everything's peachy.  Same for using a trust store.

but the trust store method is better when running as an application
and, i believe, if you have permission to run the app you should be
able to edit your trust store (perhaps someone could check that).  it
will allow you to import the certificate without recompiling the app
(like when your certificates expire).

if anyone gets the chance, test if, when using my patch the default
keystore is overidden.  if so it would be worth patching to avoid that
issue (would probably require adding a second trustmanagerfactory,
which should be simple).

i may even suggest that we would then have a simple but fairly secure
workaround for various situations.  we could even change the "default"
root certificate to the root "cacert.org" certificate.
        ... i dare say i like that idea.

--
        t
 t
                 w

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.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: java viewer source

Dale Southard
n0g0013 wrote:

> On 01.11-10:54, Dale Southard wrote:
> [ ... ]
>> As an application, embedding works fine. Just copy the viewer to a flash
>> drive or CDROM and everything's peachy.  Same for using a trust store.
>
> but the trust store method is better when running as an application
> and, i believe, if you have permission to run the app you should be
> able to edit your trust store (perhaps someone could check that).  it
> will allow you to import the certificate without recompiling the app
> (like when your certificates expire).

You can always create a trust store of your own.  The java keytool docs
should have the specifics for your underlying OS.

The default cacerts trust store is in ${JAVA_HOME}/lib/security and
shouldn't be modifiable by normal users in any reasonably secure
multiuser OS.

> if anyone gets the chance, test if, when using my patch the default
> keystore is overidden.  if so it would be worth patching to avoid that
> issue (would probably require adding a second trustmanagerfactory,
> which should be simple).

To clarify, which default?

Your patch does:

  kmf.init( ks, null ) ;
  ...
  tmf.init( ks ) ;
  ...
  context.init( kmf.getKeyManagers() , tmf.getTrustManagers(), null ) ;
  socketFactory = context.getSocketFactory() ;

Which is overriding the default trust managers with one that uses your
keystore.  Setting javax.net.ssl.trustStore won't effect this since your
trust managers set an explict truststore.

If you're content using the default trust managers, you can dispense
with all that and just do:

  socketFactory = SSLSocketFactory.getDefault();

You'll get the default --  "installed security providers will be
searched for the highest priority implementation of the appropriate
factory" and the Sun-maintained list of CAs.  The latter can be
overridden with -Djavax.net.ssl.trustStore=whatever



> i may even suggest that we would then have a simple but fairly secure
> workaround for various situations.  we could even change the "default"
> root certificate to the root "cacert.org" certificate.
> ... i dare say i like that idea.

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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.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: java viewer source

ttw+vnc
On 01.11-18:06, Dale Southard wrote:
[ ... ]
> You can always create a trust store of your own.  The java keytool docs
> should have the specifics for your underlying OS.

thanks for clarifying that.  thought there was also a "default user
keystore" that would avoid setting "javax.net.ssl.trustStore" on the
command line.

[ ... ]
> To clarify, which default?
>
> Your patch does:

*lol* i know, i didn't do it by accident.
        ;-)

[ ... ]
> Which is overriding the default trust managers with one that uses your
> keystore.  Setting javax.net.ssl.trustStore won't effect this since your
> trust managers set an explict truststore.

that was my expectation too but haven't tested that behaviour (i.e.
it occured to me that 'init' may add the keystore, not replace it).
thanks again for clarifying.

[ ... ]
> If you're content using the default trust managers, you can dispense
> with all that and just do:

the idea is (assuming you're correct about the above) to add the
"custom keystore" instead of replacing the default.  then we get "check
the default and then try the custom keystore" behaviour.  which is
what i intended to say in my last email.

this is a small patch.  it's in my todo list but don't know when
i'll get to it.

--
        t
 t
                 w

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.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: java viewer source

Dale Southard
n0g0013 wrote:
> On 01.11-18:06, Dale Southard wrote:
> [ ... ]
>> You can always create a trust store of your own.  The java keytool docs
>> should have the specifics for your underlying OS.
>
> thanks for clarifying that.  thought there was also a "default user
> keystore" that would avoid setting "javax.net.ssl.trustStore" on the
> command line.

I think that's OS-dependent.  Not sure though.

>
> [ ... ]
>> To clarify, which default?
>>
>> Your patch does:
>
> *lol* i know, i didn't do it by accident.
> ;-)

I figured, just making sure vnc-tight-devel would be able to follow our
babbling.  :-)

>> If you're content using the default trust managers, you can dispense
>> with all that and just do:
>
> the idea is (assuming you're correct about the above) to add the
> "custom keystore" instead of replacing the default.  then we get "check
> the default and then try the custom keystore" behaviour.  which is
> what i intended to say in my last email.
>
> this is a small patch.  it's in my todo list but don't know when
> i'll get to it.

I think there OS-specific keystores that are automatically searched.  Or
at least keytool seems to have work with a default file on most OS's
that is not the sun-maintained cacerts file.  Sorry, no time to test at
the moment and get a better answer.

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

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.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
|

[patch v2] Re: java viewer source

ttw+vnc
In reply to this post by ttw+vnc
On 05.11-12:30, n0g0013 wrote:
[ ... ]
> the idea is (assuming you're correct about the above) to add the
> "custom keystore" instead of replacing the default.  then we get "check
> the default and then try the custom keystore" behaviour.  which is
> what i intended to say in my last email.
>
> this is a small patch.  it's in my todo list but don't know when
> i'll get to it.

amazing what an afternoon of skiving can achieve ... well actually
not all that much but here is a newer version of this hack.

        http://www.cameron-consulting.ie/devel/patches/vnc-tight-1.3.9-ssl-03.patch

it now adds the pre-compiled keys to the default truststore instead
of overriding the default.  this will hopefully make it generally
more useful.

there are two items outstanding

1. will this fail as an applet (no access to filesystem)?

2. need to add another flag for 'useTrustCerts' so that you can
still avoid the static certs if you need to (or more specifically,
you must request them).


ps: this still has my certificate in there, you should delete this if
you use this patch
--
        t
 t
                 w

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
VNC-Tight-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/vnc-tight-devel
12