SSL secures VNC applications
A real-world setup for desktop remote control
Want to view a desktop remotely, with more convenience than proprietary solutions and security advantages over ssh tunnelling? Here's a good way to do it, and it's a technique we haven't seen described before.
The idea is to use SSL to provide security for a simple VNC viewer embedded in a Web page. This means that essentially any Java-capable Web browser can view and interact with the remote desktop; this makes for a powerful solution to a typical situations, including telecollaboration, technical support, and provisioning.
Computer there, screen here
A computer in one location performs an operation, a person somewhere else wants to see the result. The range of situations that fit this description is enormous, and the variety of means to achieve it is almost as wide. One approach, particularly convenient when working with people who are not software specialists, is to publish a single conventional desktop as a Web URL address protected by the HTTPS protocol. "Civilian" users are comfortable selecting a hyperlink to such a desktop display, or entering the URL in their browsers' address field.
With a few minutes' effort, you can set up your own remote desktops. The crucial functional distinction of this approach has to do with authentication: rather than basing it on login-level accounts, as is typical for remote mechanisms based on ssh, IPv6, OpenVPN, and most proprietary products, we show how to set up account-password pairs for SSL. This is a particularly "lightweight" approach, one that is insulated from other uses of the desktop host. At the same time, the technology is in wide and critical use throughout the Web, and is familiar to many developers.
While it takes only a few steps to set up VNC-through-SSL, there is a delicate issue at the heart of the configuration: Java VNC clients will not connect to SSL sites that have a self-signed certificate. More precisely, the JVMs commonly used by popular browsers require certificates endorsed by a "trusted third party" certificate authority (CA).
This effectively pigeon-holes readers of this article. If you're already working with SSL, probably because you manage or develop secure Web sites, you'll be able immediately to use the same Web server and signed certificate for your VNC-through-SSL projects. If you do not have a background with SSL, though, our technique is not a good place to start. More conventional ssh tunnels, or Hamachi, or a commercial solution, would probably make an easier entry point to the world of remote desktops for you. See "Certificates and SSL" for more details.
The first step is to set up VNC server(s) and corresponding tunnels.
For this, you must have a certificate that allows you to create a
valid keyfile, including both
a private and public key. Place the key in
This example uses the TightVNC server
and display :5.
Listing 1. Starting the TightVNC server and tunnel
$ tightvncserver :5 $ stunnel -d 5705 -r 5905 -p /etc/ssl/certs/stunnel.pem
While most Linux hosts are set up so that any user can launch
vncserver, it's very likely that you'll
root privileges to use
stunnel effectively. Depending on the
security model of your host, you might best do this as
sudo stunnel ....
At this point the server should offer an unencrypted connection on address
there:5905 and an encrypted connection on address
there:5705. Verify the former with
any handy VNC viewer, directed to
yourhost:5. To confirm that
stunnel is up and running, search the system log with this command:
Listing 2. Checking if stunnel succeeded
# grep stunnel /var/log/syslog|tail -24 Aug 21 18:58:17 there stunnel: Using '5905' as tcpwrapper service name Aug 21 18:58:17 there stunnel: stunnel 3.26 on i386-pc-linux-gnu PTHREAD+LIBWRAP with OpenSSL 0.9.7e 25 Oct 2004 Aug 21 18:58:17 there stunnel: FD_SETSIZE=1024, file ulimit=1024 -> 500 clients allowed
Errors that arise -- an invalid keyfile, insufficient permissions, or a port already in use -- show up in the same log file. A missing key, for instance, appears in the log this way:
Aug 21 18:58:17 there stunnel: /etc/ssl/certs/stunnel.pem: No such file or directory (2)
With the server humming along happily on both unencrypted and encrypted
ports, we turn to the VNC Web client.
To enable it, an SSL-enabled Java VNC viewer can be downloaded from
the x11vnc project. After downloading the source tarball, the Java
code is available in x11vnc-X.Y.Z/classes/ssl/VncViewer.jar and
Set up a directory for serving the VNC content, copy
VncViewer.jar there, and create
an HTML source. This sample
HTML file allows connection to
there:5705 over SSL:
Listing 3. Connecting to there:5705
<html> <body> <applet code="VncViewer.class" archive="VncViewer.jar" width="800" height="600"> <param name="PORT" value="5705" /> <param name="HOST" value="there" /> <param name="Open New Window" value="no" /> <!-- the following helps in Opera: <param name="Cursor shape updates" value="Disable" /> --> </applet> </body> </html>
Either HTTP or HTTPS can serve this applet. Assuming the HTML and
Jar files are served over HTTP on port 80, under the
/vnc URI, then
the address http://there/vnc
will display the desktop. Remember to enable your browser
for Java! Also, note that it's
essential to use the same hostname for both the
HOST parameter and the
source address; the security model of Java applets
essentially requires this.
More tips on usage
One advantage of the use of standard components and protocols is that they can be replaced fairly easily. Much of our own development, for example, has been with the Xvnc VNC server, and several others can substitute for TightVNC in the recipe above. Note these alternatives may expect slightly different command-line arguments; in all cases, though, the idea is the same. Nearly all Linux distributions offer VNC servers packaged according to the standards of that distribution, and several of the open-source VNC projects are easy to install even from source. The most difficult part of any VNC server installation has been requirement of a specific default font. Even in this case, though, at least the remedy is clearly labelled.
There is at least one hazard in using an SSL-enabled VNC viewer
in a browser. It is feasible with all major browsers, including
Mozilla Firefox, Internet Explorer and Opera, but all of
these browsers require Java runtime 1.4 or later. This becomes
an issue with users of older Microsoft Windows operating systems,
which still rely on Microsoft JVM 1.1. In this case, the VNC viewer will
not run in Internet Explorer and will report that the
VncViewer class was not found.
The only solution is to offer a non-SSL connection to the VNC server and
suggest an upgrade of Java to any recent Java Runtime.
Most VNC servers do not share desktops, by default; that is,
any connection shuts down the previous connection. For collaboration,
technical support, and similar uses, start your server with a
command-line argument of
or similar, as its documentation specifies. This allows several
users to connect to the same desktop simultaneously.
What's the point?
Although you might have worked with VNC, Web services, Java, SSL, browsers, and so on, you may never have put them together this way. What exactly do you have now?
Certificates and SSL
We've written that if you're already using SSL, you can just re-use your certificate, and if not, then this is no time to start. This is not strictly true.
From a developer's standpoint, SSL plays at least a couple of roles:
- It encrypts and authenticates VNC traffic to make your remote desktops minimally safe in a hostile Internet world; and
- SSL opens up the capabilities of common browsers.
If your browser doesn't locate a certificate it trusts for your SSL traffic, you, and, perhaps more crucially, anyone else using a Web browser to access your desktop remotely, will see many, many warning dialogs -- unbearably many.
In this article, we've addressed this situation by advising that you use a certificate you've already bought and used. This answer says both too much and too little. The j2re 1.4 JVM from Sun, for example, demands not just a certificate from a certificate authority, but from one of the higher-end CAs, including Verisign and Thawte. Browsers that use this JVM treat cut-rate certificates just as dismissively as they do self-signed ones.
On the other hand, the main body of this article overstates the impossibility of VNC-through-SSL with self-signing. If you're willing to put up with all the browser warnings, you can at least experiment with your own certificates.
There is a puzzling overabundance of tutorials on creation of self-signed certificates that promise to make the process "easy." At one level, all it takes is execution of this command-line sequence:
Listing 4. Creation of a self-signed certificate
openssl genrsa -des3 -out server.key 1024 openssl rsa -in server.key -out server.pem openssl req -new -key server.key -out server.csr openssl x509 -req -days 3560 -in server.csr \ -signkey server.key -out server.crt cat server.pem server.crt > combined.pem
Some of these steps expect interaction at the command-line.
The most crucial question will be one about "Common Name" from the third line; for this, use the fully-qualified
domain name of the host whose desktop you'll be sharing.
Often, this is
Acquisition of the certificate is typically the hardest part of VNC-through-SSL; with the certificate in hand, you should be able to complete all the other steps in short order.
Quite a bit, in fact. For a start, this is like
screen for GUIs; that is,
you can start GUI sessions at work, use them throughout
your day with all the performance and functionality you
usually have, leave, and re-attach to those same sessions
from any Java-enabled Web browser! This is a powerful
There's more, though. VNC is very handy for teleconferencing. We use it, for example, to set up demonstrations of sophisticated graphical applications for non-technical viewers. In principle, a remote X server could serve much the same duty, but VNC gives a number of advantages:
- Its security is more manageable.
- VNC is often easier to get through firewalls than X.
- VNC viewers are easier to install than X servers -- especially the installation-free browser-based viewer.
- It's easy to serve a desktop through VNC to multiple viewers.
- VNC is generally less sensitive to network latencies.
- While X authentication (and ssh tunneling) is typically based on accounts at the /etc/passwd level, Web-based access uses HTTP(S) authentication. There's a wealth of experience on creation and maintenance of such accounts, even for temporary purposes such as a teleconference demonstration.
- VNC viewers require far less memory and related hardware than X servers.
- VNC servers typically provide for such useful configurations as read-only access.
Also key to the pieces this technique uses is that the heaviest cryptographic computational load is done by "native" code rather than Java run-times. While it's often safe to assume as a first approximation that network delays determine performance, encryption and decryption are expensive enough to make alternative techniques unusable except with very high-performance computers. Part of our delight with VNC-through-SSL is that customers can use standard software pieces on old and rather plain hardware to yield thoroughly acceptable responsiveness and snap.
You probably have different requirements and resources. You'll have to judge for yourself how this use of VNC compares with commercial offerings from Citrix, Windows Terminal services, WebEx, Hamachi, and other "remoting" solutions. What we've seen, though, is that VNC-through-SSL solves a surprising range of problems.
In a follow-up article, we'll show how to combine VNC with other virtualizations to achieve powerful resource-sharing techniques. Before wrapping up this introduction, though, it's important to remind readers that VNC has serious security issues. It's reasonable to assume that brute-force attacks against a standard VNC service, protected by only a single session password, will break through, given a few hours or days. Interest by "the bad guys" in VNC is growing rapidly; be sure you use a strong password for VNC, one with at least eight characters, preferably mixing digits, letters, and other symbols. SSL adds a great deal of protection, and you should take advantage of it if you're leaving sessions open for hours at a time. We'll look at security aspects in more detail in the follow-up.
The recipe above leverages several powerful open-source pieces, but involves almost no original programming itself. It surprised us that no one seems to have documented this same assemblage of components, and that they were so readily assembled. Look in the Related topics section for more detailed descriptions of VNC, SSL, and so on.
In our next article, we'll look in more concrete detail at a couple of specific workplaces where VNC-through-SSL helps out, and how you might adapt the technique to your own circumstances, including consideration of common corporate firewalling and proxying. We'll also explain when it can be an advantage to use "native" VNC viewers in teamwork with the browser-hosted clients this article describes.
Our special thanks to Matt Kennel, who cares as much about security as we do, and talked over with us how he puts VNC-through-SSL into action.
- Review the benefits and features of remote computing on Wikipedia.
- TightVNC is a GPLed, cross-platform implementation of VNC that boasts many advanced features, including rich compression options, a distinction between full-control and read-only, and automatic ssh tunneling. Documented projects based on TightVNC include the Xvnc Terminal Server.
- stunnel is a GNU program
that "encrypt[s] arbitrary TCP connections inside Secure Sockets
Layer ..." This project combines stunnel with VNC to make a
desktop accessible through SSL encryption. Notice that stunnel
effectively needs to be run by the owner of
stunnel.pem, which is generally
- x11vnc is "a VNC for real X displays" that the authors find indispensable for some of their OpenGL work. Tangentially, x11vnc includes an enhanced Viewer package that fits the needs of the project described in this article.
- "SSL client authentication: It's a matter of trust" (developerWorks, March 1998) introduces Secure Sockets Layer and its techniques for client authorization. For the purpose of this article, SSL can be regarded as an "add-on" that encrypts, validates, and authenticates an underlying IP protocol. The authors use it to establish secure communications between a process that serves copies of desktop interaction and a Java-equipped Web browser.
- "SSL-Explorer is a fully-featured, web-based SSL VPN server," according to its home page on SourceForge. Its features and advantages overlap those of the VNC-through-SSL technique presented here.
- "The X Window System" is the official name of the graphical toolkit that underlies nearly all Linux and UNIX desktops. "An Introduction to X11 User Interfaces," which Grant Edwards wrote over a decade ago, remains pertinent and almost entirely accurate. The remoting technique presented here works entirely at the VNC level and doesn't depend on X in any direct way; however, X is the basis for several competing approaches to remoting, so it's helpful to understand it clearly.
- "Connect securely with ssh" (developerWorks, July 2003) reviews the possibilities for remote connection. Ssh is a flexible protocol often used to build "secure tunnels." VNC tunnelled through ssh is probably the single most common remoting technology for Linux.
- "Screen is a terminal multiplexer that allows you to manage many processes through one physical terminal," according to the 2003 article, "Power Sessions with Screen." Screen is extremely useful for those who focus on the command-line. It has been available since at least 1991.
- In the developerWorks Linux zone, find more resources for Linux developers, and scan our most popular articles and tutorials.
- See all Linux tips and Linux tutorials on developerWorks.