Hi,
i am looking for a more secure plugin for the Ultravnc.
If we set Ultravnc to only use the plugin (no direct connection is allowed) and also are using the authentification and authorisation mechanism with keypairs and a high secure sessionkey (all in zebedee) than i think it can be a very secure way for remote admininistration.
Than it should be also possible to use this combination as a service.
Do you think that this is possible?
And is there anybody who can convert zebedee for this?
-thx
Update: UltraVNC 1.4.3.6 and UltraVNC SC 1.4.3.6: https://forum.uvnc.com/viewtopic.php?t=37885
Important: Please update to latest version before to create a reply, a topic or an issue: https://forum.uvnc.com/viewtopic.php?t=37864
Join us on social networks and share our announcements:
- Website: https://uvnc.com/
- GitHub: https://github.com/ultravnc
- Mastodon: https://mastodon.social/@ultravnc
- Facebook: https://www.facebook.com/ultravnc1
- X/Twitter: https://x.com/ultravnc1
- Reddit community: https://www.reddit.com/r/ultravnc
- OpenHub: https://openhub.net/p/ultravnc
Important: Please update to latest version before to create a reply, a topic or an issue: https://forum.uvnc.com/viewtopic.php?t=37864
Join us on social networks and share our announcements:
- Website: https://uvnc.com/
- GitHub: https://github.com/ultravnc
- Mastodon: https://mastodon.social/@ultravnc
- Facebook: https://www.facebook.com/ultravnc1
- X/Twitter: https://x.com/ultravnc1
- Reddit community: https://www.reddit.com/r/ultravnc
- OpenHub: https://openhub.net/p/ultravnc
Ultravnc with a Zebedee Plugin
-
Guest
Re: Ultravnc with a Zebedee Plugin
I would suggest stunnel, as this will already run as a service. It is aopen source, and IMHO has better long term support possuibilities. Zebedee as I recall is maintained by one person,Elmar wrote:Hi,
i am looking for a more secure plugin for the Ultravnc.
If we set Ultravnc to only use the plugin (no direct connection is allowed) and also are using the authentification and authorisation mechanism with keypairs and a high secure sessionkey (all in zebedee) than i think it can be a very secure way for remote admininistration.
Than it should be also possible to use this combination as a service.
Do you think that this is possible?
And is there anybody who can convert zebedee for this?
-thx
-
Guest
Re: Ultravnc with a Zebedee Plugin
p.s.I would suggest stunnel, as this will already run as a service. It is a open source, and IMHO has better long term support possuibilities. Zebedee as I recall is maintained by one person,
Zebedee
Stable Version: 2.4.1 (2002/05/29)
Development Version: 2.5.2 (2003/09/23)
Stunnel
Recent Updates
Date Item
2004-03-17: New OpenSSL-0.9.7d DLLs are available to fix an exploitable vulnerability in earlier versions.
2004-02-14: Stunnel-4.05 released.
Re: Ultravnc with a Zebedee Plugin
Sorry these wher from me.Anonymous wrote:p.s.I would suggest stunnel, as this will already run as a service. It is a open source, and IMHO has better long term support possuibilities. Zebedee as I recall is maintained by one person,
Zebedee
Stable Version: 2.4.1 (2002/05/29)
Development Version: 2.5.2 (2003/09/23)
Stunnel
Recent Updates
Date Item
2004-03-17: New OpenSSL-0.9.7d DLLs are available to fix an exploitable vulnerability in earlier versions.
2004-02-14: Stunnel-4.05 released.
PGP-keys with zebedee?Elmar wrote:But there was no authentification and authorisation mechanism in stunnel.
There is a powerfull implementation for this with PGP-keys in zebedee.
By the way, has the normal cryp-dll from Ultravnc to be installed as a service if Ultravnc is used as a service?
This is news to me. I just checked the zebedee web site and tried to google for it. Please provide a link or two wher I can check out this feature.
I did find this on the zebedee site
"Windows Service:
zebedee [-n name] -S [install[=file] | remove | run]"
Other that that you can use cygwin and sshd (http://sshwindows.sourceforge.net/) or OpenSSH for windows (http://sshwindows.sourceforge.net/).
-
Guest
Identity Checking with zebedee
From DOC
Identity Checking
By default Zebedee just establishes an encrypted channel between two points. While you know that the data is protected from snooping “on the wire” there is no guarantee that the tunnel ends up where you think it does. By default, and unless you are applying any other kind of filtering or firewalling, a Zebedee server will accept connections from any client that can reach it. If the service to which you are tunnelling does not provide any further authentication, or if it relies on checking the source IP address, then it will be potentially open to attack.
The simplest, but most basic check, that you can make is to restrict the IP addresses from which a server will accept, or to which a client will make, connections. You can do this by using the checkaddress keyword.
IP address checking is useful but not that secure. Zebedee is also open to open to “man-in-the-middle” attacks where an eavesdropper pretends to a client to be the server and intercepts all traffic before forwarding it on to the real server. If you are concerned primarily with using data compression or protecting against casual “network sniffing” then you may be happy with this situation. If, however, you want more assurance that your connection is not being “hijacked” then Zebedee provides some basic facilities for doing so.
A Zebedee server can validate the identity of the client at the other end of a tunnel provided that you are using an encrypted connection. To do so the client must use a fixed private key. The easiest way to generate such a key is by using the -p option, like this:
zebedee -p
This will output a line something like this:
privatekey "410dea0cbd9c10da057848c43a610f6bb859b769"
The string of hexadecimal digits will be different every time you run it. So, on your client system you should generate a key and save it in a file, for example:
zebedee -p > myclient.key
The file myclient.key now contains the private key that will be used by Zebedee on this system. The private key must be kept secret so you should apply appropriate protection to this file to stop unauthorised users accessing it. You now need to generate the public “fingerprint” associated with this key, which you can do as follows:
zebedee -P -f myclient.key > myclient.id
The contents of the file myclient.id will look something like this:
135f04050961d37553731250d5c6f7495f088b32 myclient
The text after the string of hexadecimal digits will be the name of the machine on which you run this. It’s just a descriptive tag so you can change it to be, for example:
135f04050961d37553731250d5c6f7495f088b32 Neil’s PC
You should now modify your client configuration file to add a line:
include "path-to-dir/myclient.key"
where “path-to-dir” is the directory in which the key file is being kept. The myclient.id file is used by any server that wishes to validate the identity of myclient. The contents are not secret and you should copy this file to the Zebedee server.
On the server you should add the contents of myclient.id to a single file containing the identity “fingerprints” of all clients you wish to validate. This file, for example called client.idlist, might look like this:
ba077f6a42bea502f517cab5685e476a713d9621 Rebecca’s PC
3ad38cb1f16957d5c535272ce27557bdaa4389c6 Ben’s PC
135f04050961d37553731250d5c6f7495f088b32 Neil’s PC
Now, to the server configuration file add the following line:
checkidfile "path-to-dir/client.idlist"
That’s it! Now only clients whose identities appear in this file will be able to create tunnels to the server. If you remove a line the client will be denied further access.
At the moment you can only have a single identity file and it is an “all or nothing” mechanism — a client can either create a tunnel to any valid target or to none at all. This may be enhanced in future.
It is also worth noting that this mechanism can equally well be used for a client to validate the identity of a server, if the server uses a fixed private key.
How does this work?
By default, Zebedee generates a new private key every time it is started. If the same modulus, generator and private key are used they will always generate the same public value for use in the Diffie-Hellman key exchange protocol. The “fingerprint” is a hash of the modulus, generator and public key. Only a person knowing the private key will be able to produce public key and successfully decrypt traffic. So, if the same combination of modulus, generator and key are seen then the identity of the client can be tied to the owner of that private key. The modulus, generator and key strings are hashed together to produce the fingerprint merely for convenience and to keep the size of the identity file small.
Identity Checking
By default Zebedee just establishes an encrypted channel between two points. While you know that the data is protected from snooping “on the wire” there is no guarantee that the tunnel ends up where you think it does. By default, and unless you are applying any other kind of filtering or firewalling, a Zebedee server will accept connections from any client that can reach it. If the service to which you are tunnelling does not provide any further authentication, or if it relies on checking the source IP address, then it will be potentially open to attack.
The simplest, but most basic check, that you can make is to restrict the IP addresses from which a server will accept, or to which a client will make, connections. You can do this by using the checkaddress keyword.
IP address checking is useful but not that secure. Zebedee is also open to open to “man-in-the-middle” attacks where an eavesdropper pretends to a client to be the server and intercepts all traffic before forwarding it on to the real server. If you are concerned primarily with using data compression or protecting against casual “network sniffing” then you may be happy with this situation. If, however, you want more assurance that your connection is not being “hijacked” then Zebedee provides some basic facilities for doing so.
A Zebedee server can validate the identity of the client at the other end of a tunnel provided that you are using an encrypted connection. To do so the client must use a fixed private key. The easiest way to generate such a key is by using the -p option, like this:
zebedee -p
This will output a line something like this:
privatekey "410dea0cbd9c10da057848c43a610f6bb859b769"
The string of hexadecimal digits will be different every time you run it. So, on your client system you should generate a key and save it in a file, for example:
zebedee -p > myclient.key
The file myclient.key now contains the private key that will be used by Zebedee on this system. The private key must be kept secret so you should apply appropriate protection to this file to stop unauthorised users accessing it. You now need to generate the public “fingerprint” associated with this key, which you can do as follows:
zebedee -P -f myclient.key > myclient.id
The contents of the file myclient.id will look something like this:
135f04050961d37553731250d5c6f7495f088b32 myclient
The text after the string of hexadecimal digits will be the name of the machine on which you run this. It’s just a descriptive tag so you can change it to be, for example:
135f04050961d37553731250d5c6f7495f088b32 Neil’s PC
You should now modify your client configuration file to add a line:
include "path-to-dir/myclient.key"
where “path-to-dir” is the directory in which the key file is being kept. The myclient.id file is used by any server that wishes to validate the identity of myclient. The contents are not secret and you should copy this file to the Zebedee server.
On the server you should add the contents of myclient.id to a single file containing the identity “fingerprints” of all clients you wish to validate. This file, for example called client.idlist, might look like this:
ba077f6a42bea502f517cab5685e476a713d9621 Rebecca’s PC
3ad38cb1f16957d5c535272ce27557bdaa4389c6 Ben’s PC
135f04050961d37553731250d5c6f7495f088b32 Neil’s PC
Now, to the server configuration file add the following line:
checkidfile "path-to-dir/client.idlist"
That’s it! Now only clients whose identities appear in this file will be able to create tunnels to the server. If you remove a line the client will be denied further access.
At the moment you can only have a single identity file and it is an “all or nothing” mechanism — a client can either create a tunnel to any valid target or to none at all. This may be enhanced in future.
It is also worth noting that this mechanism can equally well be used for a client to validate the identity of a server, if the server uses a fixed private key.
How does this work?
By default, Zebedee generates a new private key every time it is started. If the same modulus, generator and private key are used they will always generate the same public value for use in the Diffie-Hellman key exchange protocol. The “fingerprint” is a hash of the modulus, generator and public key. Only a person knowing the private key will be able to produce public key and successfully decrypt traffic. So, if the same combination of modulus, generator and key are seen then the identity of the client can be tied to the owner of that private key. The modulus, generator and key strings are hashed together to produce the fingerprint merely for convenience and to keep the size of the identity file small.