enable dsm-plugin in java viewer

[MiG]

Been using uvnc 4 quite some time, great app wich I use every day with great pleasure. Big thx 4 all the hard work on it

When I´m on holiday I usually run into a "problem", as many internet-cafes nowadays don´t let u use cd/dvd 4 security reasons. This is where the java-viewer comes in handy, fire up any java enabled browser and up you go.
But you have to reconfigure uvnc to not use dsm, else you won´t be able to connect using a browser.

So, the only feature I miss, is that I would very much like to see a dsm-enabled java-viewer!

If this isn´t possible, perhaps you can solve the disabilty to connect with the java-viewer when the dsm-plugin is activated.
This way we could have encrypted sessions with the standard viewer, while using the java-viewer when needed.

thx 4 considering and keep up the good work!
MiG

[diz]

I'm sure that development of DSM plugin integration for the java viewer would be rather time consuming, but I really like the idea of temporally disabling DSM when connecting via the java viewer for situations where I'm on a trusted network (ie. when VPN in to the same network as the target machine) as this would save time messing with viewers, plugins and keys. Any chance of this making it in to version 1 ??

[Rudi De Vos]

Perhaps ssl java viewer... next year

[UltraSam]

The problem of disabling DSM for the javaviewer is that we'd create a security weakness, making 50% of the DSM plugin advantage useless:

DSMPlugin advantages:

1. All the connection communication is encrypted, even the initial handshaking (even before password/challenge negociation).

2. If the viewer doesn't have the good RC4 key file, it can't even establish the TCP connection. This way, the fact that the 8chars-max-VNC-password is weak is not important, because the step where this password is negociated is never reached without the good RC4 file.

If we enable the JavaViewer to connect without the DSM plugin, we just waste the point 2.
You can still encrypt your communication with the Win32 viewer + DSM, but the access to your UltraVNC server is only as protected as a "regular" VNC.

[MiG]

The problem of disabling DSM for the javaviewer is that we'd create a security weakness, making 50% of the DSM plugin advantage useless: [...]

Still, 50% of the communication (connects made with the "real" viewer) would be safe. As of now, whereever I want to make the javaviewer avaible on a vnc-server, I have to completely disable the DSMPlugin!

[...]
DSMPlugin advantages:

1. All the connection communication is encrypted, even the initial handshaking (even before password/challenge negociation).

2. If the viewer doesn't have the good RC4 key file, it can't even establish the TCP connection. This way, the fact that the 8chars-max-VNC-password is weak is not important, because the step where this password is negociated is never reached without the good RC4 file.

If we enable the JavaViewer to connect without the DSM plugin, we just waste the point 2.
You can still encrypt your communication with the Win32 viewer + DSM, but the access to your UltraVNC server is only as protected as a "regular" VNC.

Why exactly would we waste point 2?
It´s mainly because there is no "good RC4-file" avaible to the java-viewer, isn´t it?

Possible solution:
RC4-files are so small they could simply be accesed just in time from any webspace avaible. This could be done by the server by asking for the URL of the RC4-file to use. This should be done after the connect is initiated by the viewer, but before the password is negociated.

Steps:
1. Type IP:Port into your browsers adress field
2. Server sends the certificate (if first time) / User accept it
3. Server prompt me for URL/Location of RC4-file
4. Server gets and verifies RC4
5. Server prompt for password using RC4


Second choice (accepting a weak java-viewer, but welcoming a secure "real-viewer"):
Isn´t it possible to include an additional checkbox "don´t use DSMPlugin with java-viewer" or as "suggested" by ULtraSam "use DSMPugin only for encrypting communication"?

I´m only a user, not a single clue about coding, so most certainly the task is much harder to implement than to expose it

SSL would be great by the way

[Rudi De Vos]

Encryption is not only used to encrypt data, but also as second authentication.

Lettings people login using java viewer when you explicit demand to use encryption is opening a backdoor in security.
The problem is that many company's demand encryption for external connections, letting the user at the viewer site making the choose (by using viewer/java viewer) is not acceptable.
Encryption required need to be a server only settings.

The key file is part of the plugin, making havy use of some
functions not implemented in the java viewer. The key on himself is of no use without a working identical plugin on server and viewer.

What you propose is to use 128bit encryption and send from time to time the password (using the java viewer) with a simple des encryption.
In that case you better disable the encryption plugin. The weakest link (java viewer) determ the security level.

Until the java viewer can also be protected, you need to make the choose to use viewer+encryption or viewer+java

[MiG]

Your right about the weakest link in the chain, should have considered that better

What I´m after in the end is a secure java-viewer, that I could use from any inet-cafe in the world, even in kiosk mode.

I guess I have to wait for the ssl enabled java-viewer to come ...

thx 4 your clear point of view

[lizard]

just one question.
will there be a reasonable merit even for canceling Java-Viewer's portability?
or has anyone already thought out a magic solution to apply the plug-ins, still not ruining Java's advantage?
(perhaps Rudi talked about it above, but i still couldn't exactly get it)
thanks.