By 'do not trust' we mean they might try to gain access to remote machines you connect to via SSVNC. Note that an untrusted local user can often obtain root access in a short amount of time; if a user has achieved that, then all bets are off for ANYTHING that you do on the workstation. It is best to get rid of Untrusted Local Users as soon as possible.
Both the SSL and SSH tunnels set up by SSVNC listen on certain ports on the 'localhost' address and redirect TCP connections to the remote machine; usually the VNC server running there (but it could also be another service, e.g. CUPS printing). These are the stunnel(8) SSL redirection and the ssh(1) '-L' port redirection. Because 'localhost' is used only users or programs on the same workstation that is running SSVNC can connect to these ports, however this includes any local users (not just the user running SSVNC.)
If the untrusted local user tries to connect to these ports, he may succeed in varying degrees to gain access to the remote machine. We now list some safeguards one can put in place to try to make this more difficult to achieve.
It probably pays to have the VNC server require a password, even though there has already been SSL or SSH authentication (via certificates or passwords). In general if the VNC Server requires SSL authentication of the viewer that helps, unless the untrusted local user has gained access to your SSVNC certificate keys.
If the VNC server is configured to only allow one viewer connection at a time, then the window of opportunity that the untrusted local user can use is greatly reduced: he might only have a second or two between the tunnel being set up and the SSVNC vncviewer connecting to it (i.e. if the VNC server only allows a single connection, the untrusted local user cannot connect once your session is established). Similarly, when you disconnect the tunnel is torn down quickly and there is little or no window of opportunity to connect (e.g. x11vnc in its default mode exits after the first client disconnects).
Also for SSL tunnelling with stunnel(8) on Unix using one of the SSVNC prebuilt 'bundles', a patched stunnel is provided that denies all connections after the first one, and exits when the first one closes. This is not true if the system installed stunnel(8) is used and is not true when using SSVNC on Windows.
The following are two experimental features that are added to SSVNC to improve the situation for the SSL/stunnel case. Set them via Options -> Advanced -> "STUNNEL Local Port Protections".
1) For SSL tunnelling with stunnel(8) on Unix there is a setting 'Use stunnel EXEC mode' that will try to exec(2) stunnel instead of using a listening socket. This will require using the specially modified vncviewer unix viewer provided by SSVNC. The mode works well and is currently set as the default.
2) For SSL tunnelling with stunnel(8) on Unix there is a setting 'Use stunnel IDENT check' (experimental) to limit socket connections to be from you (this assumes the untrusted local user has not become root on your workstation and has modified your local IDENT check service; if he has you have much bigger problems to worry about...)
There is also one simple LD_PRELOAD trick for SSH to limit the number of accepted port redirection connections. This makes the window of time the untrusted local user can connect to the tunnel much smaller. Enable it via Options -> Advanced -> "SSH Local Port Protections". You will need to have the lim_accept.so file in your SSVNC package.
The main message is to 'Watch your Back' when you connect via the SSVNC tunnels and there are users you don't trust on your workstation. The same applies to ANY use of SSH '-L' port redirections or outgoing stunnel SSL redirection services.