Rubén
Cisneros
<cisneror at tb-solutions.com>
Pablo J. Royo
<royop at tb-solutions.com>
In this concrete example, we will
stablish a secure connection between a VNC (Virtual Network Computing) client
ant its server. Although we have made tests using Microsoft Terminal Server
obtaining satisfactory results, here it is not shown how to use it, but it is so
easy and similar to VNC.
Following next steps, you will be able to see
other machine´s screen in a secure manner.
First, you need some program which adds SSL encryption to your VNC protocol, so the other side, who understands SSL, may decrypt the incoming bytes and then forward them to your VNC Server.
You can do this making your VNC client to send bytes to a STunnel daemon (http://www.stunnel.org) or using also another SPipe enabled web server. The important thing is to produce SSL encrypted outgoing bytes.
You will need this machines and network structure:
It
works as other examples: the VNC client
connects to a mod_ssl + SPipe enabled Apache (Apache on the left) OR a STunnel daemon. That wdaemon (web server or STunnel), connects to the other end web server (Apache on the right, also
with enabled mod_ssl + SPipe) and then it ciphers the communication channel,
using SSL. This servers deciphers input
bytes, then performs the the connection to VNC Server.
So, this way, VNC Client and VNC Server are
still using its native protocol, and we have used SPipe to forward and
communicate the bytes in transparent form to both of them.
If you choose to use a STunnel daemon to cipher your outgoing VNC protocol, go to POINT 2. If you use another Apache Web Server, to achieve that , we must configure our two web servers this
way, after having patched mod_ssl with Spipe.
First web server must use a
VirtualHost listening in VNC port, 5900. That port is INTERNAL to your
LAN/network, because it will receive only connections from your network, so
you DON’T need to open it in firewall.
Nobody will connect from outside your network yo it. So, you configure a
virtual host on your Apache, in 5900 port. Could we use other port? . Yes, it
depends on what your VNC Client allows you to do. However ,actually VNC uses
that port, and you can´t change it in VNC Client, so then there is no option
but use a 5900 port as your destination.
<VirtualHost *:5900>
ServerAdmin webmaster@webserver-company.com
DocumentRoot "htdocs/webserver-company.com/"
ServerName webserver-company.com
ErrorLog
logs/ssl/error_log
CustomLog logs/ssl/access_log common
SSLEngine on
# Number
of second Spipe will expect bytes from client
# before
forwarding to SSLSPipeUrl
# Address
to which SPipe will forward VNC incoming bytes
# ‘s’
letter in port stands for “secure” forwarding
# This
Apache server will receive raw VNC protocol bytes, so it must
# handle
input as such, with no SSL.
SSLSPipeUrl
webserver-delegacion.com:443s
SSLCertificateFile
conf/certs/webserver-empresa. crt
SSLCertificateKeyFile
conf/certs/webserver-empresa.key
</VirtualHost>
As you see, that VirtualHost has, apart from other normal directives, somo
others:
SSLSPipeWait 2
This is the time in seconds SPipe will
wait before assuming that connection will not send any byte, so he must forward
it to configured server in next directive. As you will be receivin a LAN
connection, 2 or 3 seconds will suffice.
SSLSPipeUrl
webserver-delegacion.com:443s
This is
the server to which your incomming non-SSL connection will be forwarded. Here,
you will forward bytes ciphering them for next apache server, so you put a ‘s’
letter to indicate Spipe it must cipher outgoing forwarded bytes.
SSLSPipeInputNoSSL
This
directive is to say SPipe don´t to decipher incoming bytes, because they arrive
without SSL. If not set, Spipe would try to read bytes as if they came with SSL,
thus giving rise error.
POINT TWO
Now, you
must configure the second web server, so it will receive incoming SSL ciphered
bytes (remember ‘s’ letter on first server forward.This was its reason) and
will decipher them, forwarding deciphered protocol to final real VNC server.
So, to enable your
443 secure port to receive VNC you put:
<VirtualHost *:443>
ServerAdmin webmaster@webserver-delegacion.com
DocumentRoot htdocs/webserver-delegacion.com
ServerName
webserver-delegacion.com
ErrorLog logs/ssl/error_log
CustomLog logs/ssl/access_log common
SSLEngine on
SSLSPipeWait 2
# Address
to which you will forward incoming deciphered bytes
# if they
are not HTTP.(VNC in this case)
# I.e ,
this is your final VNC server
SSLSPipeUrl
host-VNCserver:5900
SSLCertificateFile
conf/certs/webserver-delegacion.crt
SSLCertificateKeyFile
conf/certs/webserver-delegacion.key
</VirtualHost>
Notice we
don’t need here SSLInputNoSSL directive, because this server WILL receibe SSL
ciphered bytes.
The
omportant thing here, is to forward incomming deciphered protocol to its final
server, which is a VNC server.
Let’s test this
system.
Lets supose you have installed your final Windows VNCServer in host-VNCserver, listening and waiting for connections to arrive. As a background task, you will have an icon in your task bar:
Now you
launch your VNC client as allways, but giving as destination not your final
VNCServer (which could be thousands of miles in other LAN) but your configured
outgoing Apache machine:
So, if you are going
to use the 0 display:
And now, after
clicking OK button the connection should proceed, but in a secure way.
This is the Real VNC client we have use, but there are some others:
http://www.realvnc.com: You can download the client and
server programs, and the source code, for Windows and Linux.