Option for fallbacking to nonencrypted connection

[roytam1]

With encryption enabled, all connections requires encrypted with DSM plugins.
But it is nice to have a option that allowing nonencrypted connections connecting to server. It would be more flexible for users.

[UltraSam]

IMHO it's a security risk to allow non encrypted connections even when an encryption plugin is required on a server.

That's why we haven't allowed the JavaViewer (that doesn't support DSM yet) to connect when a DSM plugin is used on the server. It would be easy to do, but I really think it's unsafe.

[roytam1]

IMHO it's a security risk to allow non encrypted connections even when an encryption plugin is required on a server.

That's why we haven't allowed the JavaViewer (that doesn't support DSM yet) to connect when a DSM plugin is used on the server. It would be easy to do, but I really think it's unsafe.

So this option is unchecked by default. When checking this option, popup a message to notify users that allowing nonencrypted connections is unsafe.
When nonencrypted connections connect the server, a "warning" event log generates.
I think this will help.

[roytam1]

And what about vice versa condition?
Client side using DSM plugins to connect to server, server side has DSM plugins but not enable them.
Will they connect?

[UltraSam]

All data sent by the viewer would be encrypted... so the server would have to implement and return a special error code to the viewer to tell it not to encrypt its data... a lot of work...

[roytam1]

All data sent by the viewer would be encrypted... so the server would have to implement and return a special error code to the viewer to tell it not to encrypt its data... a lot of work...

if server has DSM plugins, what about using DSM plugins for that session automaticly?

[UltraSam]

For now, there's no intitial handshaking or key exchange in DSMplugin stuff that could allow for an easy DSM/no DSM dynamic switching over the same connection session

Given the current DSM codebase, there are only 2 possibilities:

1. The server understands the very first bytes sent by the viewer: same DSMPlugin used on both sides (with same key), or clear connection -> the connection can continue and regular UltraVNC handshaking/password is done

2. The server does not understand the very first bytes sent by the viewer: the viewer is using a plugin and not the server, or the server is not using a plugin and the server does, or both are using a different plugin, or plugin encryption keys are different -> in all these cases the connection is immediatly dropped and an exception is raised in the viewer.

[redge]

hello roytam1,

despite known limit of MSRC4 (single thread)

Option for fallbacking to nonencrypted connection is available with
ultravnc 1.0.8.x and above (vncviewer and winvnc)

vncviewer.exe -dsmplugin securevncplugin.dsm -autoacceptnodsm -disablesponsor -autoacceptincoming -listen

function available only with Secure VNC DSM Plugin (multi-threaded) from Adam D. Walling and winvnc and vncviewer 1.0.8.x
allow multi vncviewer to multi winvnc (shared multi secure VNC connection)