SecureVNC Plugin

Simple, effective, and securely encrypted VNC sessions for UltraVNC

Created by Adam D. Walling

Overview

  • Configurable choice of symmetric ciphers and key lengths, including AES with key lengths up to 256-bits.
  • Public-key cryptography via RSA with key lengths up to 3072-bits.

Advertisements

Advertisements

Current Version - v2.3 - Nov 8th, 2010

  • x86 / 32-bit
  • x64 / 64-bit
  • if you feel I have provided something worthwhile to you through this plugin or my contributions to the UltraVNC project. But do not feel obligated in any way.

Quick Specifications

  • Default configuration uses 2048-bit RSA keys and 256-bit AES keys.
  • RSA public-key cryptography supports 512-, 1024-, 2048-, and 3072-bit keys.
  • Configurable choice of symmetric ciphers and keys:
    • Recommended ciphers:
      • AES: Supports 128-, 192-, and 256-bit keys.
    • Other ciphers:
      • Blowfish: Supports 56-, 128-, 192-, 256-, and 448-bit keys.
      • IDEA: Supports 128-bit keys.
      • CAST5: Supports 56- and 128-bit keys.
      • ARC4: Supports 56-, 128-, 192-, and 256-bit keys.
  • For older UltraVNC versions below 1.0.9.0, the legacy interface uses 2048-bit RSA keys and 128-bit AES keys.
  • All versions are threadsafe, allowing the UltraVNC server to host multiple simultaneous viewers.

System Requirements

  • Microsoft Windows 2000, XP, Server 2003, Vista, Server 2008, Windows 7.
  • Both x86 / 32-bit and x64 / 64-bit operating systems are supported.
  • Please use UltraVNC 1.0.9.x Beta or later (eventually) to take advantage of advanced functionality in this plugin. Alternatively you may also use the special builds based off of UltraVNC 1.0.8.2 below. Older versions will use the legacy interface instead; configuration options will be disabled.
  • Please do not use this software in any way which violates any local legal restrictions on cryptographic technology.

Downloads

  • v2.3 - Nov 8th, 2010
    • x86 / 32-bit
    • x64 / 64-bit
    • Source
    • Release notes
      • The SecureVNC plugin is now licensed and released under the LGPL v2.1.
      • The experimental/integrated/new interface is now considered release-quality and is the recommended interface. The old interface is now considered deprecated.
      • New cipher option, AES-CFB, uses the cipher feedback (CFB) mode of operation rather than output feedback (OFB).
      • New cipher option, 3AES-CFB. See the history section for more info. Standard 128-bit AES encryption is still considered secure for everyday use!
      • Some performance improvments which will minimize the delay when generating new keys.
      • Preparing to split into two editions:
        • The standard edition will use a FIPS-certified cryptographic module, which also means AES will be the only recommended and supported cipher in the standard edition.
        • Other ciphers will remain in a separate edition for users who are forced to abide by cryptographic legislation that restricts their freedoms.
      • Now using OpenSSL v0.9.8o
  • UltraVNC 1.0.9.x beta
    • The UltraVNC 1.0.9.x Beta contains all of the code used to create the special 1.0.8.2 version below, among myriad other stability and performance improvements. This is the recommended host application for the SecureVNC plugin.
  • Unofficial UltraVNC builds (based off of UltraVNC 1.0.8.2)
    • x86 / 32-bit
    • x64 / 64-bit
    • Release notes
      • These unofficial builds allow you to use the new interface for the SecureVNCPlugin without having to wait for an official UltraVNC build. Please note the 'official' UltraVNC 1.0.9.x betas include all of the code in these releases.
      • The new viewer is backwards compatible with servers using the old interface. However, servers using the new interface are not compatible with viewers using the old interface.
      • You can get specific information on the current encryption settings for the current session within the status dialog of the UltraVNC viewer.
      • In the plugin configuration dialog on the server, you can set a passphrase (up to 128 characters). This overrides the VNC password, which is limited to 8 characters. This passphrase is used to encrypt the handshake.

Installation and Setup

Download the SecureVNCPlugin.dsm and ensure your viewer and server applications are set to use it.

That is all!

Of course, you can tweak the default settings to improve security as described below.

Advanced Setup and Technical Explanation

Passphrases and client authentication keys

No pre-shared key or password required. In order to eavesdrop, an attacker must be able to actively modify the communication between the viewer and server. For best security and to prevent man-in-the-middle attacks, you must use a password or client authentication key.

Your UltraVNC password is used by default, but it is limited (by UltraVNC itself) 8 characters. You can override the UltraVNC password with a passphrase in the plugin configuration dialog. The passphrase supports up to 128 characters.

In the configuration dialog on the server, you have the option to generate client authentication keys. The server should have the public key (named *_ClientAuth.pubkey), and the viewer should have the private key (named *_ClientAuth.pkey). By cryptographically signing the communication, this prevents an active man-in-the-middle attack, since the handshake cannot be tampered with without invalidating the signature. This is ideal for remote support / single click situations, since the server can be publicly distributed with the public key for authentication. The viewer's private key must remain protected.

In general, place the key files in the same path as the SecureVNCPlugin.dsm. The files are searched for in the plugin's path, then the path of the parent process, then in the current directory. If an evironment variable would actually be of use to you, let me know.

The portion of the filename before the _ClientAuth will be sent in the handshake as the key identifier. This allows the viewer to choose the appropriate client authentication key for the connection. For example, if the server is using First_ClientAuth.pubkey, the viewer will attempt to find First_ClientAuth.pkey. Once you change the server to use Second_ClientAuth.pubkey, the viewer will then attempt to find Second_ClientAuth.pkey; however, the viewer would still be able to connect to servers that are still using First_ClientAuth.pubkey. If the key is not found, it will revert to using the first *_ClientAuth.pkey that it can.

Cryptographic options

The Use new key algorithm option should always be selected, unless you need to maintain compatibility with viewers who are using v2.2.0.0 or v2.2.1.0

The Use 56-bit Blowfish cipher for passphrase option should always be disabled, unless you need to use small key sizes to comply with cryptographic restrictions. When this option is disabled, the passphrase is used to generate a 256-bit key for use with the AES cipher.

The various ciphers can be enabled or disabled, along with the supported key sizes. The server will notify the viewer which ciphers and keysizes it allows, and the viewer will choose the best combination among them. In general, this goes from top-down same as the order in the dialog. AES is chosen first, follows by Blowfish, then IDEA, CAST5, and ARC4. For example, although Blowfish has a larger maximum key length, AES will always be chosen in preference of it if it is enabled. So, to use 448-bit Blowfish, you must disable AES entirely and enable the 448-bit key length.

The least secure ciphers exist mostly to assist with compliance with local cryptographic laws, and for the benefit of viewers running on embedded or mobile devices that may not have the processor power or the legal clearance to use more advanced ciphers and longer key lengths. Eventually these other ciphers will be deprecated and moved to a separate module. However, all ciphers available are at least somewhat secure, although ARC4 is by far the worst of them all. If ARC4 is used, the first 3 kilobytes of the keystream are discarded to avoid a known attack.

The RSA size affects the size of the client authentication keys that you generate, and the public keys that are automatically generated by the server. Note that changing the size will not affect any client authentication keys that you are already using, and the client authentication key does not need to be the same size as the server's public key. You can use a 512-bit server public key with a 3072-bit client authentication key, or vice versa. The 2048-bit RSA key length is chosen by default; you can increase this to 3072-bit if desired, at the expense of a larger handshake. There is also some research in progress which may have found some theoretical weaknesses in RSA keys that exceed 2048-bits, but that is still preliminary.

It is highly recommended to choose a passphrase. This will override the UltraVNC password, which due to a historic design limitation in VNC is limited to 8 characters. The passphrase override allows you to use up to 128 characters. This passphrase is used to encrypt the handshake and effectively prevents man-in-the-middle attacks. The key is generated from the passphrase along a salt by using 4,096 rounds with the PKCS#5 PBKDF2 HMAC SHA1 key derivation algorithm.

History

  • v2.3 - Nov 8th, 2010
    • The SecureVNC plugin is now licensed and released under the LGPL v2.1.
    • The experimental/integrated/new interface is now considered release-quality and is the recommended interface. This requires UltraVNC 1.0.9.x or above (or the unofficial 1.0.8.2 builds). The old interface is now considered deprecated.
    • New cipher option, AES-CFB, uses the cipher feedback (CFB) mode of operation rather than output feedback (OFB). This will eventually become the default.
    • New cipher option, 3AES-CFB. This also uses CFB mode. Three independent keys are used. To encrypt, E1+D2+E3. To decrypt, D3+E2+D1. Note that this is effectively three times slower. This mode was introduced specifically to address the related-key attack described here. It is obviously similar to 3DES. AES appears to be a non-group cipher, so it benefits the same way DES does. Regardless, standard 128-bit AES encryption is still considered secure for everyday use. However if there is one thing I've learned by creating an encryption plugin, it is that people are very paranoid about their data!
    • Some performance improvments which will minimize the delay when generating new keys.
    • Preparing to split into two editions:
      • The standard edition will use a FIPS-certified cryptographic module, which also means AES will be the only recommended and supported cipher in the standard edition.
      • Other ciphers will remain in a separate edition for users who are forced to abide by cryptographic legislation that restricts their freedoms.
    • Now using OpenSSL v0.9.8o
  • v2.2.4.0 - Jun 7th, 2010
    • Fixes a client authentication bug in the experimental interface.
  • v2.2.3.0 - May 26th, 2010
    • Replaces the previous release. This provides various UI improvements and more cryptographic options for the new interface.
    • New interface (newer than UltraVNC 1.0.8.2; see UltraVNC 1.0.9.x betas or unofficial 1.0.8.2 builds)
      • New key derivation algorithm based on PKCS#5 v2.0 PBKDF2. This differs from v2.2.1.0. This significantly increases the difficulty of brute-force attacks by using over 4,000 rounds with the PKCS#5 PBKDF2 HMAC SHA1 key derivation algorithm.
  • v2.2.1.0 - May 15th, 2010
    • Changes to previous v2.2.0.0 version are all limited to the new interface. If you downloaded v2.2.0.0 and intend to use the new interface using either my unofficial UltraVNC builds or the official UltraVNC builds from the future, you must download v2.2.1.0, or you will experience a crash due to changes in the interface definition.
  • v2.2.0.0 - May 12th, 2010
    • Fixes crash due to UltraVNC host attempting to encrypt a buffer using the legacy method after the socket has been closed and interface has been freed.
    • Client authentication has been changed. If you are using client authentication, you must update both the server and the client to this version. Otherwise, this is backwards compatible with v1.0.2.0.
    • ARC4 is being phased out. If there is any interest in it, please let me know, but for now we shall only use AES.
    • OpenSSL 0.9.8n fixes issue that caused a significant delay initializing the pseudo-random number generator.
    • New interface (newer than UltraVNC 1.0.8.2; see UltraVNC 1.0.9.x betas or unofficial 1.0.8.2 builds)
      • The new interface allows more detailed error messages to be provided to the host application (such as the UltraVNC viewer and server).
      • Improved UI and expanded symmetric cipher selections.
      • Increased RSA key size selections.
      • Option to encrypt initial handshake with smaller keys (for compliance with international cryptographic regulations).
      • Plugin configuration settings are now persisted via the host (for the UltraVNC server, this means they are stored in the .ini file or the registry.)
      • In the plugin configuration dialog on the server, you can set a passphrase (up to 128 characters). This overrides the VNC password, which is limited to 8 characters. This passphrase is used to encrypt the handshake.
      • If the server is using the new key derivation algorithm, then a client will need the new plugin to be able to connect. However a client with the new plugin can successfully connect to a server running all versions of the plugin.
      • Changes to previous v2.2.0.0 and v2.2.1.0 versions are all limited to this new interface.
    • Classic interface (UltraVNC 1.0.8.2 or lower)
      • Client authentication has been changed. If you are using client authentication, you must update both the server and the client to this version. Otherwise, this is backwards compatible with v1.0.2.0.
      • ARC4 is being phased out. If there is any interest in it, please let me know, but for now we shall only use AES.
  • v1.0.2.0 - 2009
    • Properly supports Windows 2000 (Removed Interlocked SList functions)
    • Added feature to sign and verify the public key created by the server.
  • Initial Release Candidate

Troubleshooting

Please check the UltraVNC forums for further help and information, or to see if your question has already been answered.

Contact

Comments, suggestions, and criticisms are encouraged!

The author can be contacted via e-mail (adam.walling@gmail.com) or via the UltraVNC forums (adzm).

Please visit the UltraVNC forums for help with UltraVNC, the latest news and developments, and a plethora of other software and solutions provided by the community.

Advertisements

I decided to allow hosting some text advertisements. These (hopefully) relevant ads below and to the right of the page may direct you to other products that fit your needs.

Legalities

This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version.

Copyright (C) 2010 Adam D. Walling aka Adzm. All Rights Reserved.

Copyright (C) 1998-2008 The OpenSSL Project. All rights reserved.

Copyright (C) 2005 UltraVnc. All Rights Reserved.

This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org/)

The author is not liable in any way for any usage of this library.