Encryption without key exchange

cat101 · Post by **cat101** » 2005-01-14 15:08

The MSRC4Plugin.dsm plugins great but is not convenient for machines I connect from time to time because I would have to exchange keys on every machine I plan to access.

Having an encrypted session and authentication based on a password would be great (basically like ssh)

Thanks

cat101

bodyhead · Post by **bodyhead** » 2005-01-27 20:17

I agree. An encripted session would make this the only VNC server/client to use.

Post by **UltraSam** » 2005-01-27 21:37

It is quite easy to make a DSMPlugin based on this idea.

It takes the VNC password and creates an 128 bit MD5 hash from it, as the encryption key.
So you'd better use a 8 chars VNC password in this case...
It's weaker at the logon level because you don't need the key file but it works fine and strongly encrypts the communication anyway.

It would be easy to create a version of the MSRC4 DSMplugin that does the same thing instead of using a RC4 key file.

Sean, what do you think ?

scovel · Post by **scovel** » 2005-01-27 22:39

I think you are REALLY lucky I saw this. I rarely frequent the forum.

It is VERY disappointing that the VNC password is only 8 characters. More characters would be more secure.

You'll still have to visit each machine to install and configure the plugin. Enabling the plugin will make it impossible to connect to the machine with other VNC clients. It would be less secure, and the only benefit would be you didn't have to copy a key file. (1K file!) Does this still sound like a good idea?

Sean

scovel · Post by **scovel** » 2005-01-27 22:48

Maybe what we really need is to implement a more generic encryption methodology.

Here's the thought. Add an extension to the RFB protocol. One that can be negotiated during the connection (like the encoding methods). The extension would be 128bit SSL encryption.

A key exchange method like SSL uses would need to be added. If the client and the server both support the extension, then keys would be exchanged, and the session would be encrypted.

If the extension wasn't supported on both ends, then the session would be a typical clear-text session. You would also need to allow the server to block non-encrypted sessions if the administrator wanted ALL sessions to be encrypted.

The actual encryption could still be in a plugin (so you won't get into trouble with your government, Sam) but it would have to be negotiated as part of the RFB negotiation.

Sam, what do you think?

Sean

redge · Post by **redge** » 2005-01-27 22:50

Maybe what we really need is to implement a more generic encryption methodology.

so nice idea...let's go, you staff can do it !

SSH with password, active dsm plugin and use password as seen on host with ssl, I think must be available to majority secure connection without learning about to much security issue !
Like you just need basic course for drive a car !

UltraVNC remote control secure easy a must have !

Because use rc4.key (at my level) thinking need to be like an engineer to use it

all my tests with an encrypted connection with UltraVNC fails

scovel · Post by **scovel** » 2005-01-28 01:10

Redge,

You can't get it to work? Did you try the latest "noreg" version?

Seems like English isn't your first language (sorry). Perhaps the plugin wasn't looking in the right place for the key. The new version is much more undertanding when English isn't your main language.

If you need help getting it going let me know. If I need to make my directions more clear, let me know.

Sean

Post by **UltraSam** » 2005-01-28 09:11

Sean,

I think it sounds good.
The only problem is that it requires a rfb protocole modification, whith a key exchange, which is not planned for V1...
Going to work on this though.

The function to provide the key to the plugin is already in the DSM API so it would require almost no modification at this level as well as in the plugin.

You are right, VNC password 8 chars max is weak. That's why along the MD5 hash I had added a > 8 chars password support
(if no plugin, only take the 8 VNC password first chars, if plugin take up to 16 chars in the VNC password... kinda tricky but working

scovel · Post by **scovel** » 2005-01-28 14:47

Hey, If Tight and Real can add protocol extensions, why not Ultra?

Let me know if I can help with this.

Sean

P.S. What IS planned for V1? Is there a list somewhere?

Post by **Rudi De Vos** » 2005-01-28 15:58

You mean V2?

V1 is just stabalizing current version, no addons.
WE never reach V1 if we keep making changes.

V2?
Need to be prepared for longhorn.....
Service split needed.
The rfb protocol for this is less important

If the number of developpers increase, we need to look for a more modular way of programming.
Making modules more independend then the current approach.

That's my point of view...

Rudi

Guest · Post by **Guest** » 2005-02-04 23:53

Hi guys,
your reasoning are correct in principle, but think to a system administrator.

He might have to install vnc on multiple machines and all would like to have is the possibility to add that very little bit of extra security wihout leaving the communication completly open to anyone. Why do you feel that an MD5 hash (even if with a weak key) would not be appreciated? It would!

Yes, it is not secure, but it is a step forward from clear communication...... I certainly would be using such plugin if it was developed and many other would as well!
Go for a soimple solution now instead of waiting for protocol changes!

Jason Smith · Post by **Jason Smith** » 2005-02-18 22:14

First of all, after having used a couple of the VNC viewers, let me congratulate you guys. Nice work. TightVNC was the pits on XP Home, and RealVNC seems to be very plain-vanilla. You guys have added a lot of convenience features, and it is much appreciated!

It seems from this conversation that there is something wrong with the VNC spec that does not allow you to use normal encryption methods, or maybe does not specify how they are supposed to be used.

It seems to me like you could use a diffie-helmann key exchange, or an RSA key exchange, and do away with the need for exchanging symmetric keys. This would be far more secure, since a new temporary symmetric key would be generated each time you connected.

And yeah, that might not be compatible with other VNC implementations, but it sure would make UltraVNC kick booty. The only thing that the other guys have going for them, as far as I can tell, is their support for encryption.

And you can always support the non-secure protocol for other viewers and servers.

Or can you? Am I oversimplifying here? I know just enough to be dangerous...

So what is wrong with having your own proprietary extension to the spec? Edumacate me!

UltraVNC

Encryption without key exchange

Encryption without key exchange

Agreed

What I think

Maybe THIS is what you want...

No!

Go for it!

For us regular folk, could someone explain the problem here?