The simplest scheme ("x11vnc -ssl") is where
x11vnc generates a
temporary, self-signed certificate each time (automatically using
openssl(1)) and the VNC viewer client accepts the certificate
without question (e.g. user clicks "Yes" in a dialog box. Perhaps the
dialog allows them to view the certificate too). Also note stunnel's
default is to quietly accept all certificates.
The encryption this provides protects against all passive sniffing of the VNC traffic and passwords on the network and so it is quite good, but it does not prevent a Man-In-The-Middle attack: e.g. an attacker intercepts the VNC client stream and sends it his own Public key for SSL negotiation (pretending to be the server). Then it makes a connection to SSL x11vnc itself and forwards the data back and forth. He can see all the traffic and modify it as well.
Most people don't seem to worry about Man-In-The-Middle attacks these days; they are more concerned about passive sniffing. Perhaps someday that will change if attack tools are created that make it simpler to perform the attack.
If you are not worried about Man-In-The-Middle attacks you do not have to read the techniques described in the rest of this page.
To prevent Man-In-The-Middle attacks, certificates must somehow
be verified. This requires the VNC client side have some piece of
information that can be used to verify the SSL x11vnc server.
Alternatively, although rarely done, x11vnc could verify VNC
Clients' certificates, see the
-sslverify
option that is discussed briefly below.
There are a number of ways to have the client authenticate x11vnc. The quickest way perhaps would be to copy (safely) the certificate x11vnc prints out:
26/03/2006 21:12:00 Creating a temporary, self-signed PEM certificate... ... -----BEGIN CERTIFICATE----- MIIC4TCCAkqgAwIBAgIJAMnwCaOjvEKaMA0GCSqGSIb3DQEBBAUAMIGmMQswCQYD VQQGEwJBVTEOMAwGA1UEBxMFTGludXgxITAfBgNVBAsTGGFuZ2VsYS0xMTQzNDI1 NTIwLjQxMTE2OTEPMA0GA1UEChMGeDExdm5jMS4wLAYDVQQDEyV4MTF2bmMtU0VM (more lines) ... -----END CERTIFICATE-----to the client machine(s) and have the client's SSL machinery (e.g. stunnel, Web Browser, or Java plugin) import the certificate. That way when the connection to x11vnc is made the client can verify that is it the desired server on the other side of the SSL connection.
So, for example suppose the user is using the SSL enabled Java VNC Viewer and has incorporated the x11vnc certificate into his Web browser on the viewing side. If he gets a dialog that the certificate is not verified he knows something is wrong. It may be a Man-In-The-Middle attack, but more likely x11vnc certificate has changed or expired or his browser was reinstalled and lost the certificate, etc, etc.
As another example, if the user was using
stunnel with his VNC viewer (this is mentioned
in this FAQ), e.g.
STUNNEL.EXE on Windows, then he
would have to set the "CAfile = path-to-the-cert" and
"verify = 2" options in the stunnel.conf file before
starting up the tunnel.
If a x11vnc certificate cannot be verified, stunnel will drop
the connection (and print a failure message in its log file).
A third example, using the VNC viewer on Unix with stunnel the wrapper
script can be used this way:
"ss_vncviewer -verify ./x11vnc.crt far-away.east:0"
where ./x11vnc.crt is the copied certificate x11vnc
printed out.
Note that in principle the copying of the certificate to the client machine(s) itself could be altered in a Man-In-The-Middle attack! You can't win. It is unlikely the attacker could predict how you were going to send it unless you had, say, done it many times before the same way. SSH is a very good way to send it (but of course it too depends on public keys being sent unaltered between the two machines!). If you are really paranoid, I'm sure you'll figure out a really good way to transport the certificates. See the Certificate Authority scheme below for a way to make this easier (you just have to do it once).
Now, it would be very inconvenient to copy the new temporary certificate
every time x11vnc is run in SSL mode. So for convenience
there is the "SAVE" keyword to instruct x11vnc
to save the certificate it creates:
x11vnc -ssl SAVE -display :0 ...This way it will save the certificate and private key in these files:
~/.vnc/certs/server.crt ~/.vnc/certs/server.pemThe ".crt" file contains only the certificate and should be copied to the VNC Viewer machine(s) that will be authenticating the x11vnc server. The ".pem" file contains both the certificate and the private key and should be kept secret. (If you don't like the default location
~/.vnc/certs, e.g. it is on an NFS share
and you are worried about local network sniffing, use the
-ssldir dir
option to point to a different directory.)
So the next time you run "x11vnc -ssl SAVE ..." it will
read the server.pem file directly instead of creating a new one.
You can manage multiple SSL x11vnc server keys in this simple way by using:
x11vnc -ssl SAVE-key2 -display :0 ...etc, where you put whatever name you choose for the key after "
SAVE-".
E.g. "-ssl SAVE-fred".
Also, if you want to be prompted to possibly change
the made up names, etc. that x11vnc creates
(e.g. "x11vnc-SELF-SIGNED-CERT-7762" for the CommonName)
for the certificates distinguished name (DN), then use
"x11vnc -ssl SAVE_PROMPT ...",
"x11vnc -ssl SAVE_PROMPT-fred ..." etc. when you create the key the
first time.
Tip: when prompting, if you choose the CommonName entry to be the full internet hostname of the machine the clients will be connecting to then that will avoid an annoying dialog box in their Web browsers that warn that the CommonName doesn't match the hostname.
Well, since now with the "SAVE" keyword the certificate and key
will be longer lived, one can next worry about somebody stealing the private
key and pretending to be the x11vnc server! How to guard against this?
The first is that the file is created with perms 600 (i.e. -rw-------)
to make it harder for an untrusted user to copy the file.
A better way is to also encrypt the private key with a passphrase.
You are prompted whether you want to do this or not when the
key is first created under "-ssl SAVE" mode
("Protect key with a passphrase? [y]/n").
It is suggested that you use a passphrase. The inconvenience is
every time you run "x11vnc -ssl SAVE ..."
you will need to supply the passphrase to access the private key:
06/04/2006 11:39:11 using PEM /home/runge/.vnc/certs/server.pem 0.000s A passphrase is needed to unlock an OpenSSL private key (PEM file). Enter passphrase>before x11vnc can continue.
A very sophisticated way that scales well if the number of users is large is to use a Certificate Authority (CA) whose public certificate is available to all of the VNC clients and whose private key has been used to digitally sign the x11vnc server certificate(s).
The idea is as follows:
-ssl SAVE")As above, it is important the CA private key and the x11vnc server key are kept secret, otherwise someone could steal them and pretend to be the CA or the x11vnc server if they copied the key. It is recommended that the x11vnc server keys are also protected via a passphrase (see the previous section).
Optionally, VNC viewer certs and keys could also be generated to enable the x11vnc server to authenticate each client. This is not normally done (usually a simple viewer password scheme is used), but this can be useful in some situations. These optional steps go like this:
-sslverify CA")-sslverify)
Some utility commands are provided to ease the cert+key creation, signing,
and management:
-sslGenCA,
-sslGenCert,
-sslDelCert,
-sslEncKey,
-sslCertInfo.
They basically run the openssl(1) command for you to
manage the certs/keys. It is required that openssl(1)
is installed on the machine and available in PATH.
All commands can be pointed to an alternate toplevel certificate directory via the
-ssldir option
if you don't want to use the default ~/.vnc/certs.
1) To generate your Certificate Authority (CA) cert and key run this:
x11vnc -sslGenCAFollow the prompts, you can modify any information strings you care to. You will also be required to encrypt the CA private key with a passphrase. This generates these files:
~/.vnc/certs/CA/cacert.pem (the CA public certificate) ~/.vnc/certs/CA/private/cakey.pem (the CA private key)If you want to use a different directory use
-ssldir
It must supplied with all subsequent SSL utility options to point them
to the correct directory.
2) To generate a signed x11vnc server cert and key run this:
x11vnc -sslGenCert serverAs with the CA generation, follow the prompts and you can modify any information strings you care to. This will create the files:
~/.vnc/certs/server.crt (the server public certificate) ~/.vnc/certs/server.pem (the server private key + public cert)
It is recommended to protect the server private key with a passphrase (you will be prompted whether you want to). You will need to provide it whenever you start x11vnc using this key.
3) Start up x11vnc using this server key:
x11vnc -ssl SAVE -display :0 ...(
SAVE corresponds to server.pem, see
-sslGenCert server somename
info on creating additional server keys, server-somename.crt ...)
4) Next, safely copy the CA certificate to the VNC viewer (client) machine(s). Perhaps:
scp ~/.vnc/CA/cacert.pem clientmachine:.
5) Then the tricky part, make it so the SSL VNC Viewer uses this certificate. There are a number of ways this might be done, it depends on what your client and/or SSL tunnel is. Some examples:
For the SSL Java VNC viewer supplied with x11vnc in
classes/ssl/VncViewer.jar or
classes/ssl/SignedVncViewer.jar:
cacert.pem cert into your Web Browser
(e.g. Edit -> Preferences -> Privacy & Security -> Manage Certificates -> WebSites -> Import)
cacert.pem cert into your Java Plugin
(e.g. run ControlPanel, then Security -> Certificates -> Secure Site -> Import)
cacert.pem file in some dialog. Note that the Web
browser or Java plugin is used for the server authentication. If the user
gets a "Site not verified" message while connecting he should investigate
further.
For the use of stunnel (e.g. on Windows) one would add this to the stunnel.conf:
# stunnel.conf: client = yes options = ALL CAfile = /path/to/cacert.pem # or maybe C:\path\to\cacert.pem [myvncssl] accept = 5901 connect = far-away.east:5900(then point the VNC viewer to
localhost:1).
Here is an example for the Unix stunnel wrapper script ss_vncviewer:
ss_vncviewer -verify ./cacert.pem far-away.east:0
To create additional x11vnc server keys do something like this:
x11vnc -sslGenCert server myotherkeyand use it this way:
x11vnc -ssl SAVE-myotherkey ...The files will be
~/.vnc/certs/server-myotherkey.{crt,pem}
You can also create a self-signed server key:
x11vnc -sslGenCert server self:third_keyand use it this way:
x11vnc -ssl SAVE-self:third_key ...This key is not signed by your CA. This can be handy to have a key set separate from your CA when you do not want to create a 2nd CA cert+key.
You don't have to use your own CA cert+key you can use a third party's. Perhaps you have a company-wide CA or you can even have your x11vnc certificate signed by a professional CA (e.g. www.thawte.com or www.verisign.com).
The advantage to doing this is that the VNC client machines will already have the CA certificates installed and you don't have to install it on each machine.
To generate an x11vnc server cert+key this way you should generate a "request" for a certicate signing something like this:
x11vnc -sslGenCert server req:externalThis will create the request file:
~/.vnc/certs/server-req:external.reqWhich you should send to the external CA. When you get the signed certificate back from them, save it in the file:
~/.vnc/certs/server-req:external.crtand create the .pem this way:
mv ~/.vnc/certs/server-req:external.key ~/.vnc/certs/server-req:external.pem chmod 600 ~/.vnc/certs/server-req:external.pem cat ~/.vnc/certs/server-req:external.crt >> ~/.vnc/certs/server-req:external.pemYou also rename the two files (.crt and .pem) to have a shorter basename if you like.
You can optionally create certs+keys for your VNC client machines as well. After distributing them to the client machines you can have x11vnc verify the clients using SSL. Here is how to do this:
x11vnc -sslGenCert client dilbert x11vnc -sslGenCert client wally x11vnc -sslGenCert client alice ...As usual, follow the prompts if you want to change any of the info field values. As always, it is a good idea to protect the private keys with a passphrase. These files are created:
~/.vnc/certs/clients/dilbert.crt ~/.vnc/certs/clients/dilbert.pem ...Note that these are kept in a
clients subdirectory.
Next, safely copy the .pem files to each corresponding client machine and incorporate them into the VNC viewer / SSL software (see the ideas mentioned above for the CA and server keys). The only difference is these certificates might be referred to as "My Certificates" or "Client Certificates". They are used for client authentication (which is relatively rare for SSL).
After copying them you can delete the clients/*.pem files for
extra safety because the private keys are not needed by the x11vnc
server. You don't really need the clients/*.crt files
either (because they have been signed by the CA). But they could come
in handy if you wanted to let in just one client and are necessary
for self-signed client certificates.
Now start up x11vnc and instruct it to verify connecting clients via SSL and the CA cert:
x11vnc -ssl SAVE -sslverify CA
For arbitrary self-signed client certificates (no CA) it might be something like this:
x11vnc -ssl SAVE -sslverify path/to/client.crt x11vnc -ssl SAVE -sslverify path/to/client-hash-dir x11vnc -ssl SAVE -sslverify path/to/certs.txtWhere
client.crt would be an individual client certificate;
client-hash-dir a directory of file names based on md5 hashes
of the certs (see
-sslverify);
and certs.txt signifies a single file full of client certificates.
Finally, connect with your VNC viewer using the key. Here is an example for the Unix stunnel wrapper script ss_vncviewer: using client authentication (and the standard server authentication with the CA cert):
ss_vncviewer -mycert ./dilbert.pem -verify ./cacert.pem far-away.east:0Our SSVNC enhanced tightvnc viewer can also use these openssl
.pem files (you can load them via
Certs... -> MyCert dialog).
It is also possible to use
-sslverify
on a per-client key basis, and also using self-signed client keys
(x11vnc -sslGenCert client self:dilbert)
Now a tricky part is to get Web browsers or Java Runtime to import and
use the openssl .pem cert+key files. See the next paragraph
on how to convert them to pkcs12 format. If you find a robust way
to import them and and get them to use the cert please let us know!
Here is how to convert our openssl crt/pem files to pkcs12 format (contains both the client certificate and key) that can be read by Web browsers and Java for use in client authentication:
openssl pkcs12 -export -in mycert.crt -inkey mycert.pem -out mycert.p12it will ask for a passphrase to protect
mycert.p12.
Some software (e.g. Java ControlPanel) may require a non-empty passphrase.
Actually, since our .pem contains both the certificate and
private key, you could just supply it for the -in and remove
the -inkey option.
It appears that for certificates only importing, our .crt
file is sufficient and can be read by Mozilla/Firefox and Java...
If you have trouble getting your Java Runtime to import and use
the cert+key, there is a workaround for the
SSL-enabled Java applet.
On the Web browser URL that retrieves the VNC applet, simply add a "/?oneTimeKey=..."
applet parameter (see ssl-portal
for more details on applet parameters; you don't need to do the full portal setup though).
The value of the oneTimeKey will be the very long
string that is output of the onetimekey program
found in the classes/ssl x11vnc directory.
Or you can set oneTimeKey=PROMPT in which case the
applet will ask you to paste in the long string. These scheme is
pretty ugly, but it works. A nice application of it is to make
one time keys for users that have already logged into a secure HTTPS
site via password. A cgi program then makes a one time key for the logged
in user to use: it is passed back over HTTPS as the applet parameter
in the URL and so cannot be sniffed. x11vnc is run to use that key
via -sslverify.
Update: as of Apr 2007 in the 0.9.1 x11vnc tarball
there is a new option setting
"-users sslpeer="
that will do a switch user much like
-unixpw
does, but this
time using the emailAddress field of the Certificate subject
of the verified Client.
This mode requires -sslverify
turned on to verify the clients via SSL.
This mode can be useful in situations using
-create
or -svc where
a new X server needs to be started up as the authenticated user
(but unlike in -unixpw mode, the unix username is not
obviously known).
You can get information about your keys via
-sslCertInfo.
These lists all your keys:
x11vnc -sslCertInfo list x11vnc -sslCertInfo ll(the latter is long format).
These print long output, including the public certificate, for individual keys:
x11vnc -sslCertInfo server x11vnc -sslCertInfo dilbert x11vnc -sslCertInfo all (every key, very long)
If you want to add a protecting passphrase to a key originally created without one:
x11vnc -sslEncKey SAVE x11vnc -sslEncKey SAVE-fred
To delete a cert+key:
x11vnc -sslDelCert SAVE x11vnc -sslDelCert SAVE-fred x11vnc -sslDelCert wally(but
rm(1) will be just as effective).
See also this article for some some general info and examples using stunnel and openssl on Windows with VNC. Also http://www.stunnel.org/faq/certs.html