faba wrote:Thanks for your reply. I have renamed it but as you have said it is not possible with the new SC.Could somebody please fix this? The old SC isn't really usable with Vista oder Windows 7 and SecureVNC especially with the certificates is perfect for SC because of the asymmetric encrypting approach.With the old plugin if you got the exe you got the key so ...

Exactly. My motivation for all of this in the beginning was for a secure solution for SC UVNC deployment.

I will write up instructions. Unfortunately the file size will be much larger than the classic SC, but that is not usually as much of a concern these days.

From what I gleaned off the SecureVNC website, I understood that the pass phrase would replace the standard VNC 8-character password when enabled during keypair generation. However, when I use the key pair, I am not prompted for the pass phrase I had entered, and I simply enter the VNC password as usual. Will I ever use the pass phrase? Or is it only used in key generation? I'm using the 1.0.8.2 build off the SecureVNC site and just starting as a application.

Thanks!

EDIT: Interestingly, even when I remove the private key from my client installation, it can still log in using the regular VNC password - I thought that the server would be forced to use the public key? Otherwise, anyone with the dsm plugin could try to brute-force the password?
EDIT2: Also, even when I appear to be using the key pair, the password transmission has the " (not encrypted) " in the little status window... I thought this plugin encrypted the password transmission?...
EDIT3: Well, I found the answer to one issue - the passphrase is a local setting for the server's pluging configuration, and not integrated into the keypair. But it sill appears to be doing the handshake and password transmittal in "not encrypted" mode...

The encrypted communication begins after the initial handshake, at least in terms of the status window. The handshake itself is encrypted. But the data stream between the server and client is not modified until the handshake has succeeded.

Is everything working properly now? Please note that only the client auth keys should really be used.

Well, with a clientauth pubkey in the folder with the server app and a clientauth pkey in my client folder, and a pass phrase typed into the SecureVNC config window.... when I try to connect, this is what the client looks like:

Are these consistent with proper operation of a clientauth keypair? Why can I also connect to the server after deleting the pkey in my client folder? Can I make it such that the server will reject all connections from clients without a proper pkey?

Please get v2.2.4.0 from the website. This fixes the client auth
issue on servers, as well as a few minor changes. Note the bug only affected the experimental interface, not the classic one. However with this resolved I would consider the experimental interface complete.

The handshake has to be 'unencrypted' because the keys have not yet been established. However the handshake itself consists of encrypted data using RSA and AES. The passphrase is used, along with a salt, to generate the AES key that is used to protect the handshake. So don't worry; the passphrase is never sent over the wire at all.

Additionally, even without a passphrase, the handshake is safe from eavesdropping. However there is the possibility of the communication being modified rather than passively watched. In that case, there must be a shared secret. The passphrase is one such shared secret, and an easy one to 'carry' with you. However anyone with access to the settings can easily get the key, if you are using it for remote support situations. That is where the client authentication comes in. The public client auth key for the server can be public with no worries. The private key signs the handshake to ensure communication is coming from an authorized client.

Of course both passphrase and client auth can be
mixed.

My apologies for the client auth issue; the check was accidentally bypassed due to unremoved debug code in the experimental interface. This will not happen again; I am finally moving the code to sourceforge so I can do proper diffs on commit.

Thanks so much for all your efforts in both keeping this SecureVNC tool updated and also explaining the basics to a non-expert like me! It's obvious that, while I consider myself very computer savy, I am nowhere near your level. I can locate, download, try, use, and tweak almost any software tool I desire on the internet - but I'm playing by the coders' rules. You, my friend, make the rules. And for that, I am grateful.

Quick question - I saw the passing phrase about 3072bit keys possibly being less secure than 2048 - what do you recommend using? I always assumed that a longer key was better, as long as your bandwidth and computing power could accomodate the additional required resources without affecting use experience. Shoud I drop my RSA key length back down to 2048?

I'm having a heck of a time - between two win 7 computers, I got everything working, but my other configuration just won't work.

The server machine is a Windows XP (Media Center 2005) 32 bit machine, and the client is a Win 7 x64 box.

I have the server configured properly (I think), although it was always asking me what user I wanted to run as - I started invoking all the start / stop / install / remove actions as admin, I don't know if that helped...

In any case, when I try to connect from the Win 7 box to the XP box, I just get the following message after I enter my password.

"Response failed client authentication"

I've checked my password umpteen times and I'm sure I'm typing in the right thing, yet it fails to work.

Is there a summary of the encryption choices and how they impact the server's - or client's - CPU?

I enabled AES-CFB and AES both with 256 byte key lengths and a P4 computer I am using as a client for testing went to 99.5% CPU! The server is a Quad core Intel i5 2.8 GHz. The load was hardly a blip on it.....

I changed to ARC4 and 128-bit key length and that seems better for the poor P4 client. What other low-overhead combinations are there?

lwc wrote:I use the latest official UVNC client version 1.0.9.6.1 but the configuration options for this plugin are all disabled. Why and how many bits of defense do I get?

Also, the "Generate Server Key (advanced)" button does work. Can you explain what it does?

You don't get to choose the "options" for the plugin on the client side. The server side controls all of that. In the server's version of that dialog you will find everything works. BUT you don't actually need to change anything. Its all pre-set to work with very secure encryption.

Don't monkey with the "Generate Server Key" stuff until after you read all the plugin docs. Chances are you do not need to do anything other than ENABLE the plugin at both ends.

lwc wrote:I'm sorry, I forgot to mention the viewer would use the plugin to access multiple SingleClicks. What does it take to enable the options and how many bits of defense do I get by default?

The plugin's docs don't mention that advanced option, which is why I ask in here.

Yeah, I tripped over it someplace deep when I was reading up on this. Same answer: you don't want to change that unless you have a special need.

The Plugin is controlled on the server side, and I think the default is AES 256-bit encryption. You will see what it is set to when you open the Plugin control panel on the server. I changed all of mine to ARC4 56-bits. I'm only really interested in having more secure passwords on my connection than worrying somebody will want to spy on my remote sessions. I find the reduced settings faster to connect and reduces the network load.

If your going to use the VNC Viewer GUI for your connections, you can CHECK or UNCHECK the "Use DSMPlugin" for each session. I find it MUCH more useful to make SHORTCUTs with different command-line options for each machine I want to remote control. Then you can pre-specify all the options you want.

For example, a non-secure connection would have a shortcut properties of:

I use both of these in Windows XP Pro SP3. Up to this Windows version, command line parameters go OUTSIDE of the quotation marks around the programs' path string. This may not always be the case, I leave it to the reader to adapt to your Windows version.

Also, if your using a 64-bit O/S then the Plugin name is different. I leave it to the reader to adapt as needed.

lwc wrote:The server is SC. Where is the plugin's control panel there?

Ah well, the good news is the INI settings for the "winvnc.exe" server are usually in the same folder as the EXE (ultravnc.ini) and the plugin settings are controlled by a couple of lines in the admin section:

This is what I'm using for my "reduced" encryption (ARC4 56-bit), no password in the plugin. The bad news is I can't remember where SC puts it - it could be bundled inside the EXE. After using SC I decided to switch to ChunkVNC instead. And after I used that for a while, I figured out (with Process Explorer) the Ultra VNC commands Chunk uses I switched back to uVNC since it was a newer version than what ChunkVNC was using at that time.

I still use SC and ChunkVNC for a few friends and clients that have special needs and/or are squeamish about my having 24/7 access to their machines....

That string is a Windows Shortcut to run vncviewer.exe. As per the command line syntax, the last item has to be the IP address of the VNC server you want to connect too (unless you are using a repeater).

Hi Guys,I just wanted to let you know that I've just released new builds of SmartCode VNC Manager and ViewerX VNC ActiveX control that offer built-in support for SecureVNC v2.3. Please do give them a try!

when i install UltraVNC 1.0.9.6.2 there is a SecureVNCPlugin64.dsm in the program folder.Its also the version 2.3.0.0 but its not the same file as this from http://adamwalling.com/SecureVNC.Why is this so? Wich is the newest/right one?

NO, just the date we signed the files differ for both webservers.Yes, if encryption is used the password is also encrypted.Yes, when you use keys you don't need an extra password, i keep both, just in casei loose my usb stick.