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.

Back to top

The recipe

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 /etc/ssl/certs/stunnel.pem. This example uses the TightVNC server and display :5.

$ 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 need 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:

# grep stunnel /var/log/syslog|tail -24
Aug 21 18:58:17 there stunnel[5453]: Using '5905' as 
      tcpwrapper service name
Aug 21 18:58:17 there stunnel[5453]: 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[5454]: 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[5453]: /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 x11vnc-X.Y.Z/classes/ssl/SignedVncViewer.jar. 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:

<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.

Back to top

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 -alwaysshared or similar, as its documentation specifies. This allows several users to connect to the same desktop simultaneously.

Back to top

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?

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 tool.

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 Resources section for more detailed descriptions of VNC, SSL, and so on.

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:

    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 `hostname`.

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.

Back to top

Summary

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.

Resources

Learn

• Review the benefits and features of remote computing on Wikipedia.
  
  
• "Create a VNC system with tclRFB" (developerWorks, August 2003) introduces the VNC technology and shows how easily you can customize it. For remote desktops, you can use standard VNC, but VNC's flexibility means that it's easy to enhance the remoting system through adjustments at the VNC level.
  
  
• 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 root.
  
  
• 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.
  
  
• "Hamachi is a zero-configuration virtual private networking application", according to its home page. There's no charge for the "core version," although the Linux release is currently available only as a console application.
  
  
• "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.
  
  
• Stay current with developerWorks technical events and Webcasts.
  
  

Get products and technologies

• With IBM trial software, available for download directly from developerWorks, build your next development project on Linux.
  
  

Discuss

• Get involved in the My developerWorks community; with your personal profile and custom home page, you can tailor developerWorks to your interests and interact with other developerWorks users.
  
  

About the authors

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Computer there, screen here
• The recipe
• More tips on usage
• What's the point?
• Summary
• Resources
• About the authors
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community

Dig deeper into Linux on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers