set REL8x

x11vnc/x11vnc.1

@@ -2,7 +2,7 @@
 .TH X11VNC "1" "July 2006" "x11vnc " "User Commands"
 .SH NAME
 x11vnc - allow VNC connections to real X11 displays
-         version: 0.8.2, lastmod: 2006-07-11
+         version: 0.8.2, lastmod: 2006-07-12
 .SH SYNOPSIS
 .B x11vnc
 [OPTION]...
@@ -388,10 +388,6 @@ to the program location and in standard locations
 (/usr/local/share/x11vnc/classes, etc).  Under \fB-ssl\fR or
 \fB-stunnel\fR the ssl classes subdirectory is sought.
 .PP
-\fB-http_ssl\fR
-.IP
-As \fB-http,\fR but force lookup for ssl classes subdir.
-.PP
 \fB-connect\fR \fIstring\fR
 .IP
 For use with "vncviewer -listen" reverse connections.
@@ -555,160 +551,6 @@ used to have viewonly passwords.  (tip: make the 3rd
 and last line be "__BEGIN_VIEWONLY__" to have 2
 full-access passwords)
 .PP
-\fB-unixpw\fR \fI[list]\fR
-.IP
-Use Unix username and password authentication.  x11vnc
-uses the 
-.IR su (1)
-program to verify the user's password.
-[list] is an optional comma separated list of allowed
-Unix usernames.  See below for per-user options that
-can be applied.
-.IP
-A familiar "login:" and "Password:" dialog is
-presented to the user on a black screen inside the
-vncviewer.  The connection is dropped if the user fails
-to supply the correct password in 3 tries or does not
-send one before a 25 second timeout.  Existing clients
-are view-only during this period.
-.IP
-Since the detailed behavior of 
-.IR su (1)
-can vary from
-OS to OS and for local configurations, test the mode
-carefully on your systems before using it in production.
-Test different combinations of valid/invalid usernames
-and valid/invalid passwords to see if it behaves as
-expected.  x11vnc will attempt to be conservative and
-reject a login if anything abnormal occurs.
-.IP
-On FreeBSD and the other BSD's by default it is
-impossible for the user running x11vnc to validate
-his *own* password via 
-.IR su (1)
-(evidently commenting out
-the pam_self.so entry in /etc/pam.d/su eliminates this
-problem).  So the x11vnc login will always *fail* for
-this case (even when the correct password is supplied).
-.IP
-A possible workaround for this would be to start
-x11vnc as root with the "\fB-users\fR \fI+nobody\fR" option to
-immediately switch to user nobody.  Another source of
-problems are PAM modules that prompt for extra info,
-e.g. password aging modules.  These logins will fail
-as well even when the correct password is supplied.
-.IP
-**IMPORTANT**: to prevent the Unix password being sent
-in *clear text* over the network, one of two schemes
-will be enforced: 1) the \fB-ssl\fR builtin SSL mode, or 2)
-require both \fB-localhost\fR and \fB-stunnel\fR be enabled.
-.IP
-Method 1) ensures the traffic is encrypted between
-viewer and server.  A PEM file will be required, see the
-discussion under \fB-ssl\fR below (under some circumstances
-a temporary one can be automatically generated).
-.IP
-Method 2) requires the viewer connection to appear
-to come from the same machine x11vnc is running on
-(e.g. from a ssh \fB-L\fR port redirection).  And that the
-\fB-stunnel\fR SSL mode be used for encryption over the
-network.(see the description of \fB-stunnel\fR below).
-.IP
-Note: as a convenience, if you 
-.IR ssh (1)
-in and start
-x11vnc it will check if the environment variable
-SSH_CONNECTION is set and appears reasonable.  If it
-does, then the \fB-ssl\fR or \fB-stunnel\fR requirement will be
-dropped since it is assumed you are using ssh for the
-encrypted tunnelling.  \fB-localhost\fR is still enforced.
-Use \fB-ssl\fR or \fB-stunnel\fR to force SSL usage even if
-SSH_CONNECTION is set.
-.IP
-To override the above restrictions you can set
-environment variables before starting x11vnc:
-.IP
-Set UNIXPW_DISABLE_SSL=1 to disable requiring either
-\fB-ssl\fR or \fB-stunnel.\fR  Evidently you will be using a
-different method to encrypt the data between the
-vncviewer and x11vnc: perhaps 
-.IR ssh (1)
-or an IPSEC VPN.
-.IP
-Note that use of \fB-localhost\fR with 
-.IR ssh (1)
-is roughly
-the same as requiring a Unix user login (since a Unix
-password or the user's public key authentication is
-used by sshd on the machine where x11vnc runs and only
-local connections from that machine are accepted)
-.IP
-Set UNIXPW_DISABLE_LOCALHOST=1 to disable the \fB-localhost\fR
-requirement in Method 2).  One should never do this
-(i.e. allow the Unix passwords to be sniffed on the
-network).
-.IP
-Regarding reverse connections (e.g. \fB-R\fR connect:host
-and \fB-connect\fR host), when the \fB-localhost\fR constraint is
-in effect then reverse connections can only be used
-to connect to the same machine x11vnc is running on
-(default port 5500).  Please use a ssh or stunnel port
-redirection to the viewer machine to tunnel the reverse
-connection over an encrypted channel. Note that in \fB-ssl\fR
-mode reverse connection are disabled (see below).
-.IP
-In \fB-inetd\fR mode the Method 1) will be enforced (not
-Method 2).  With \fB-ssl\fR in effect reverse connections
-are disabled.  If you override this via env. var, be
-sure to also use encryption from the viewer to inetd.
-Tip: you can also have your own stunnel spawn x11vnc
-in \fB-inetd\fR mode (thereby bypassing inetd).  See the FAQ
-for details.
-.IP
-The user names in the comma separated [list] can have
-per-user options after a ":", e.g. "fred:opts"
-where "opts" is a "+" separated list of
-"viewonly", "fullaccess", "input=XXXX", or
-"deny", e.g. "karl,wally:viewonly,boss:input=M".
-For "input=" it is the K,M,B,C described under \fB-input.\fR
-.IP
-If a user in the list is "*" that means those
-options apply to all users.  It also means all users
-are allowed to log in after supplying a valid password.
-Use "deny" to explicitly deny some users if you use
-"*" to set a global option.
-.IP
-There are also some utilities for testing password
-if [list] starts with the "%" character.  See the
-quick_pw() function in the source for details.
-.PP
-\fB-unixpw_nis\fR \fI[list]\fR
-.IP
-As \fB-unixpw\fR above, however do not use 
-.IR su (1)
-but rather
-use the traditional 
-.IR getpwnam (3)
-+ 
-.IR crypt (3)
-method to
-verify passwords instead.  This requires that the
-encrypted passwords be readable.  Passwords stored
-in /etc/shadow will be inaccessible unless x11vnc
-is run as root.
-.IP
-This is called "NIS" mode simply because in most
-NIS setups the user encrypted passwords are accessible
-(e.g. "ypcat passwd").  NIS is not required for this
-mode to work (only that 
-.IR getpwnam (3)
-return the encrypted
-password is required), but it is unlikely it will work
-for any other modern environment unless x11vnc is run
-as root (which, btw, is often done when running x11vnc
-from inetd and xdm/gdm/kdm).  All of the \fB-unixpw\fR options
-and contraints apply.
-.PP
 \fB-display\fR \fIWAIT:...\fR
 .IP
 A special usage mode for the normal \fB-display\fR option.
@@ -736,47 +578,6 @@ output is taken as XAUTHORITY data.  It can be either
 of the form XAUTHORITY=<file> or raw xauthority data for
 the display (e.g. "xauth extract - $DISPLAY" output).
 .IP
-In the case of \fB-unixpw\fR (but not \fB-unixpw_nis),\fR then the
-above command is run as the user who just authenticated
-via the login and password prompt.
-.IP
-Also in the case of \fB-unixpw,\fR the user logging in can
-place a colon at the end of his username and supply
-a few options: scale=, scale_cursor= (or sc=), solid,
-id=, clear_mods (or cm), clear_keys (or ck), repeat, or
-speeds= separated by commas if there is more than one.
-After the user logs in successfully, these options will
-be applied to the VNC screen.  For example,
-.IP
-login: fred:scale=3/4,repeat
-Password: ...
-.IP
-for convenience m/n implies scale= e.g. fred:3/4
-To disable this set the environment variable
-X11VNC_NO_UNIXPW_OPTS=1.  To set any other options,
-the user can use the gui (x11vnc \fB-gui\fR connect) or the
-remote control method (x11vnc \fB-R\fR opt:val) during his
-VNC session.
-.IP
-So the combination of \fB-display\fR WAIT:cmd=... and
-\fB-unixpw\fR allows automatic pairing of an unix
-authenticated VNC user with his desktop.  This could
-be very useful on SunRays and also any system where
-multiple users share a given machine.  The user does
-not need to remember special ports or passwords set up
-for his desktop and VNC.
-.IP
-A nice way to use WAIT:cmd=... is out of 
-.IR inetd (8)
-(it automatically forks a new x11vnc for each user).
-You can have the x11vnc inetd spawned process run as,
-say, root or nobody.  When run as root (for either inetd
-or display manager), you can also supply the option
-"\fB-users\fR \fIunixpw=\fR" to have the x11vnc process switch to
-the user as well.  Note: there will be a 2nd SSL helper
-process that will not switch, but it is only encoding
-and decoding the encrypted stream at that point.
-.IP
 As a special case, WAIT:cmd=FINDDISPLAY will run a
 script that works on most Unixes to determine a user's
 DISPLAY variable and xauthority data (see 
@@ -801,544 +602,6 @@ e.g. WAIT:1280x1024:... to set the size of the display
 the VNC client first attaches to since some VNC viewers
 will not automatically adjust to a new framebuffer size.
 .PP
-\fB-ssl\fR \fI[pem]\fR
-.IP
-Use the openssl library (www.openssl.org) to provide a
-built-in encrypted SSL tunnel between VNC viewers and
-x11vnc.  This requires libssl support to be compiled
-into x11vnc at build time.  If x11vnc is not built
-with libssl support it will exit immediately when \fB-ssl\fR
-is prescribed.
-.IP
-[pem] is optional, use "\fB-ssl\fR \fI/path/to/mycert.pem\fR"
-to specify a PEM certificate file to use to identify
-and provide a key for this server.  See 
-.IR openssl (1)
-for
-more info about PEMs and the \fB-sslGenCert\fR option below.
-.IP
-The connecting VNC viewer SSL tunnel can optionally
-authenticate this server if they have the public
-key part of the certificate (or a common certificate
-authority, CA, is a more sophisicated way to verify
-this server's cert, see \fB-sslGenCA\fR below).  This is
-used to prevent man-in-the-middle attacks.  Otherwise,
-if the VNC viewer accepts this server's key without
-verification, at least the traffic is protected
-from passive sniffing on the network (but NOT from
-man-in-the-middle attacks).
-.IP
-If [pem] is not supplied and the 
-.IR openssl (1)
-utility
-command exists in PATH, then a temporary, self-signed
-certificate will be generated for this session (this
-may take 5-30 seconds on slow machines).  If 
-.IR openssl (1)
-cannot be used to generate a temporary certificate
-x11vnc exits immediately.
-.IP
-If successful in using 
-.IR openssl (1)
-to generate a
-temporary certificate, the public part of it will be
-displayed to stderr (e.g. one could copy it to the
-client-side to provide authentication of the server to
-VNC viewers.)  See following paragraphs for how to save
-keys to reuse when x11vnc is restarted.
-.IP
-Set the env. var. X11VNC_SHOW_TMP_PEM=1 to have x11vnc
-print out the entire certificate, including the PRIVATE
-KEY part, to stderr.  One could reuse this cert if saved
-in a [pem] file.  Similarly, set X11VNC_KEEP_TMP_PEM=1
-to not delete the temporary PEM file: the file name
-will be printed to stderr (so one could move it to
-a safe place for reuse).  You will be prompted for a
-passphrase for the private key.
-.IP
-If [pem] is "SAVE" then the certificate will be saved
-to the file ~/.vnc/certs/server.pem, or if that file
-exists it will be used directly.  Similarly, if [pem]
-is "SAVE_PROMPT" the server.pem certificate will be
-made based on your answers to its prompts for info such
-as OrganizationalName, CommonName, etc.
-.IP
-Use "SAVE-<string>" and "SAVE_PROMPT-<string>"
-to refer to the file ~/.vnc/certs/server-<string>.pem
-instead.  E.g. "SAVE-charlie" will store to the file
-~/.vnc/certs/server-charlie.pem
-.IP
-See \fB-ssldir\fR below to use a directory besides the
-default ~/.vnc/certs
-.IP
-Example: x11vnc \fB-ssl\fR SAVE \fB-display\fR :0 ...
-.IP
-Reverse connections are disabled in \fB-ssl\fR mode because
-there is no way to ensure that data channel will
-be encrypted.  Set X11VNC_SSL_ALLOW_REVERSE=1 to
-override this.
-.IP
-Your VNC viewer will also need to be able to connect
-via SSL.  See the discussion below under \fB-stunnel\fR and
-the FAQ (ssl_vncviewer script) for how this might be
-achieved.  E.g. on Unix it is easy to write a shell
-script that starts up stunnel and then vncviewer.
-Also in the x11vnc source a SSL enabled Java VNC Viewer
-applet is provided in the classes/ssl directory.
-.PP
-\fB-ssldir\fR \fI[dir]\fR
-.IP
-Use [dir] as an alternate ssl certificate and key
-management toplevel directory.  The default is
-~/.vnc/certs
-.IP
-This directory is used to store server and other
-certificates and keys and also other materials.  E.g. in
-the simplest case, "\fB-ssl\fR \fISAVE\fR" will store the x11vnc
-server cert in [dir]/server.pem
-.IP
-Use of alternate directories via \fB-ssldir\fR allows you to
-manage multiple VNC Certificate Authority (CA) keys.
-Another use is if ~/.vnc/cert is on an NFS share you
-might want your certificates and keys to be on a local
-filesystem to prevent network snooping (for example
-\fB-ssldir\fR /var/lib/x11vnc-certs).
-.IP
-\fB-ssldir\fR affects nearly all of the other \fB-ssl*\fR options,
-e.g. \fB-ssl\fR SAVE, \fB-sslGenCert,\fR etc..
-.PP
-\fB-sslverify\fR \fI[path]\fR
-.IP
-For either of the \fB-ssl\fR or \fB-stunnel\fR modes, use [path]
-to provide certificates to authenticate incoming VNC
-*Client* connections (normally only the server is
-authenticated in SSL.)  This can be used as a method
-to replace standard password authentication of clients.
-.IP
-If [path] is a directory it contains the client (or CA)
-certificates in separate files.  If [path] is a file,
-it contains multiple certificates.  See special tokens
-below.  These correspond to the "CApath = dir" and
-"CAfile = file" stunnel options.  See the 
-.IR stunnel (8)
-manpage for details.
-.IP
-Examples:
-x11vnc \fB-ssl\fR \fB-sslverify\fR ~/my.pem
-x11vnc \fB-ssl\fR \fB-sslverify\fR ~/my_pem_dir/
-.IP
-Note that if [path] is a directory, it must contain
-the certs in separate files named like <HASH>.0, where
-the value of <HASH> is found by running the command
-"openssl x509 \fB-hash\fR \fB-noout\fR \fB-in\fR file.crt". Evidently
-one uses <HASH>.1 if there is a collision...
-.IP
-The the key-management utility "\fB-sslCertInfo\fR \fIHASHON\fR"
-and "\fB-sslCertInfo\fR \fIHASHOFF\fR" will create/delete these
-hashes for you automatically (via symlink) in the HASH
-subdirs it manages.  Then you can point \fB-sslverify\fR to
-the HASH subdir.
-.IP
-Special tokens: in \fB-ssl\fR mode, if [path] is not a file or
-a directory, it is taken as a comma separated list of
-tokens that are interpreted as follows:
-.IP
-If a token is "CA" that means load the CA/cacert.pem
-file from the ssl directory.  If a token is "clients"
-then all the files clients/*.crt in the ssl directory
-are loaded.  Otherwise the file clients/token.crt
-is attempted to be loaded.  As a kludge, use a token
-like ../server-foo to load a server cert if you find
-that necessary.
-.IP
-Use \fB-ssldir\fR to use a directory different from the
-~/.vnc/certs default.
-.IP
-Note that if the "CA" cert is loaded you do not need
-to load any of the certs that have been signed by it.
-You will need to load any additional self-signed certs
-however.
-.IP
-Examples:
-x11vnc \fB-ssl\fR \fB-sslverify\fR CA
-x11vnc \fB-ssl\fR \fB-sslverify\fR self:fred,self:jim
-x11vnc \fB-ssl\fR \fB-sslverify\fR CA,clients
-.IP
-Usually "\fB-sslverify\fR \fICA\fR" is the most effective.
-See the \fB-sslGenCA\fR and \fB-sslGenCert\fR options below for
-how to set up and manage the CA framework.
-.IP
-NOTE: the following utilities, \fB-sslGenCA,\fR \fB-sslGenCert,\fR
-\fB-sslEncKey,\fR and \fB-sslCertInfo\fR are provided for
-completeness, but for casual usage they are overkill.
-.IP
-They provide VNC Certificate Authority (CA) key creation
-and server / client key generation and signing.  So they
-provide a basic Public Key management framework for
-VNC-ing with x11vnc. (note that they require 
-.IR openssl (1)
-be installed on the system)
-.IP
-However, the simplest usage mode (where x11vnc
-automatically generates its own, self-signed, temporary
-key and the VNC viewers always accept it, e.g. accepting
-via a dialog box) is probably safe enough for most
-scenarios.  CA management is not needed.
-.IP
-To protect against Man-In-The-Middle attacks the
-simplest mode can be improved by using "\fB-ssl\fR \fISAVE\fR"
-to have x11vnc create a longer term self-signed
-certificate, and then (safely) copy the corresponding
-public key cert to the desired client machines (care
-must be taken the private key part is not stolen;
-you will be prompted for a passphrase).
-.IP
-So keep in mind no CA key creation or management
-(-sslGenCA and \fB-sslGenCert)\fR is needed for either of
-the above two common usage modes.
-.IP
-One might want to use \fB-sslGenCA\fR and \fB-sslGenCert\fR
-if you had a large number of VNC client and server
-workstations.  That way the administrator could generate
-a single CA key with \fB-sslGenCA\fR and distribute its
-certificate part to all of the workstations.
-.IP
-Next, he could create signed VNC server keys
-(-sslGenCert server ...) for each workstation or user
-that then x11vnc would use to authenticate itself to
-any VNC client that has the CA cert.
-.IP
-Optionally, the admin could also make it so the
-VNC clients themselves are authenticated to x11vnc
-(-sslGenCert client ...)  For this \fB-sslverify\fR would be
-pointed to the CA cert (and/or self-signed certs).
-.IP
-x11vnc will be able to use all of these cert and
-key files.  On the VNC client side, they will need to
-be "imported" somehow.  Web browsers have "Manage
-Certificates" actions as does the Java applet plugin
-Control Panel.  stunnel can also use these files (see
-the ssl_vncviewer example script in the FAQ.)
-.PP
-\fB-sslGenCA\fR \fI[dir]\fR
-.IP
-Generate your own Certificate Authority private key,
-certificate, and other files in directory [dir].
-.IP
-If [dir] is not supplied, a \fB-ssldir\fR setting is used,
-or otherwise ~/.vnc/certs is used.
-.IP
-This command also creates directories where server and
-client certs and keys will be stored.  The 
-.IR openssl (1)
-program must be installed on the system and available
-in PATH.
-.IP
-After the CA files and directories are created the
-command exits; the VNC server is not run.
-.IP
-You will be prompted for information to put into the CA
-certificate.  The info does not have to be accurate just
-as long as clients accept the cert for VNC connections.
-You will also need to supply a passphrase of at least
-4 characters for the CA private key.
-.IP
-Once you have generated the CA you can distribute
-its certificate part, [dir]/CA/cacert.pem, to other
-workstations where VNC viewers will be run.  One will
-need to "import" this certicate in the applications,
-e.g. Web browser, Java applet plugin, stunnel, etc.
-Next, you can create and sign keys using the CA with
-the \fB-sslGenCert\fR option below.
-.IP
-Examples:
-x11vnc \fB-sslGenCA\fR
-x11vnc \fB-sslGenCA\fR  ~/myCAdir
-x11vnc \fB-ssldir\fR ~/myCAdir \fB-sslGenCA\fR
-.IP
-(the last two lines are equivalent)
-.PP
-\fB-sslGenCert\fR \fItype\fR \fIname\fR
-.IP
-Generate a VNC server or client certificate and private
-key pair signed by the CA created previously with
-\fB-sslGenCA.\fR  The 
-.IR openssl (1)
-program must be installed
-on the system and available in PATH.
-.IP
-After the Certificate is generated the command exits;
-the VNC server is not run.
-.IP
-The type of key to be generated is the string \fItype\fR.
-It is either "server" (i.e. for use by x11vnc) or
-"client" (for a VNC viewer).  Note that typically
-only "server" is used: the VNC clients authenticate
-themselves by a non-public-key method (e.g. VNC or
-unix password).  \fItype\fR is required.
-.IP
-An arbitrary default name you want to associate with
-the key is supplied by the \fIname\fR string.  You can
-change it at the various prompts when creating the key.
-\fIname\fR is optional.
-.IP
-If name is left blank for clients keys then "nobody"
-is used.  If left blank for server keys, then the
-primary server key: "server.pem" is created (this
-is the saved one referenced by "\fB-ssl\fR \fISAVE\fR" when the
-server is started)
-.IP
-If \fIname\fR begins with the string "self:" then
-a self-signed certificate is created instead of one
-signed by your CA key.
-.IP
-If \fIname\fR begins with the string "req:" then only a
-key (.key) and a certificate signing *request* (.req)
-are generated.  You can then send the .req file to
-an external CA (even a professional one, e.g. Thawte)
-and then combine the .key and the received cert into
-the .pem file with the same basename.
-.IP
-The distinction between "server" and "client" is
-simply the choice of output filenames and sub-directory.
-This makes it so the \fB-ssl\fR SAVE-name option can easily
-pick up the x11vnc PEM file this option generates.
-And similarly makes it easy for the \fB-sslverify\fR option
-to pick up your client certs.
-.IP
-There is nothing special about the filename or directory
-location of either the "server" and "client" certs.
-You can rename the files or move them to wherever
-you like.
-.IP
-Precede this option with \fB-ssldir\fR [dir] to use a
-directory other than the default ~/.vnc/certs You will
-need to run \fB-sslGenCA\fR on that directory first before
-doing any \fB-sslGenCert\fR key creation.
-.IP
-Note you cannot recreate a cert with exactly the same
-distiguished name (DN) as an existing one.  To do so,
-you will need to edit the [dir]/CA/index.txt file to
-delete the line.
-.IP
-Similar to \fB-sslGenCA,\fR you will be prompted to fill
-in some information that will be recorded in the
-certificate when it is created.  Tip: if you know
-the fully-quailified hostname other people will be
-connecting to you can use that as the CommonName "CN"
-to avoid some applications (e.g. web browsers and java
-plugin) complaining it does not match the hostname.
-.IP
-You will also need to supply the CA private key
-passphrase to unlock the private key created from
-\fB-sslGenCA.\fR  This private key is used to sign the server
-or client certicate.
-.IP
-The "server" certs can be used by x11vnc directly by
-pointing to them via the \fB-ssl\fR [pem] option.  The default
-file will be ~/.vnc/certs/server.pem.  This one would
-be used by simply typing \fB-ssl\fR SAVE.  The pem file
-contains both the certificate and the private key.
-server.crt file contains the cert only.
-.IP
-The "client" cert + private key file will need
-to be copied and imported into the VNC viewer
-side applications (Web browser, Java plugin,
-stunnel, etc.)  Once that is done you can delete the
-"client" private key file on this machine since
-it is only needed on the VNC viewer side.  The,
-e.g. ~/.vnc/certs/clients/<name>.pem contains both
-the cert and private key.  The <name>.crt contains the
-certificate only.
-.IP
-NOTE: It is very important to know one should always
-generate new keys with a passphrase.  Otherwise if an
-untrusted user steals the key file he could use it to
-masquerade as the x11vnc server (or VNC viewer client).
-You will be prompted whether to encrypt the key with
-a passphrase or not.  It is recommended that you do.
-One inconvenience to a passphrase is that it must
-be suppled every time x11vnc or the client app is
-started up.
-.IP
-Examples:
-.IP
-x11vnc \fB-sslGenCert\fR server
-x11vnc \fB-ssl\fR SAVE \fB-display\fR :0 ...
-.IP
-and then on viewer using ssl_vncviewer stunnel wrapper
-(see the FAQ):
-ssl_vncviewer \fB-verify\fR ./cacert.crt hostname:0
-.IP
-(this assumes the cacert.crt cert from \fB-sslGenCA\fR
-was safely copied to the VNC viewer machine where
-ssl_vncviewer is run)
-.IP
-Example using a name:
-.IP
-x11vnc \fB-sslGenCert\fR server charlie
-x11vnc \fB-ssl\fR SAVE-charlie \fB-display\fR :0 ...
-.IP
-Example for a client certificate (rarely used):
-.IP
-x11vnc \fB-sslGenCert\fR client roger
-scp ~/.vnc/certs/clients/roger.pem somehost:.
-rm  ~/.vnc/certs/clients/roger.pem
-.IP
-x11vnc is then started with the the option \fB-sslverify\fR
-~/.vnc/certs/clients/roger.crt (or simply \fB-sslverify\fR
-roger), and on the viewer user on somehost could do
-for example:
-.IP
-ssl_vncviewer \fB-mycert\fR ./roger.pem hostname:0
-.PP
-\fB-sslEncKey\fR \fI[pem]\fR
-.IP
-Utility to encrypt an existing PEM file with a
-passphrase you supply when prompted.  For that key to be
-used (e.g. by x11vnc) the passphrase must be supplied
-each time.
-.IP
-The "SAVE" notation described under \fB-ssl\fR applies as
-well. (precede this option with \fB-ssldir\fR [dir] to refer
-a directory besides the default ~/.vnc/certs)
-.IP
-The 
-.IR openssl (1)
-program must be installed on the system
-and available in PATH.  After the Key file is encrypted
-the command exits; the VNC server is not run.
-.IP
-Examples:
-x11vnc \fB-sslEncKey\fR /path/to/foo.pem
-x11vnc \fB-sslEncKey\fR SAVE
-x11vnc \fB-sslEncKey\fR SAVE-charlie
-.PP
-\fB-sslCertInfo\fR \fI[pem]\fR
-.IP
-Prints out information about an existing PEM file.
-In addition the public certificate is also printed.
-The 
-.IR openssl (1)
-program must be in PATH. Basically the
-command "openssl x509 \fB-text"\fR is run on the pem.
-.IP
-The "SAVE" notation described under \fB-ssl\fR applies
-as well.
-.IP
-Using  "LIST" will give a list of all certs being
-managed (in the ~/.vnc/certs dir, use \fB-ssldir\fR to refer
-to another dir).  "ALL" will print out the info for
-every managed key (this can be very long).  Giving a
-client or server cert shortname will also try a lookup
-(e.g. \fB-sslCertInfo\fR charlie).  Use "LISTL" or "LL"
-for a long (ls \fB-l\fR style) listing.
-.IP
-Using "HASHON" will create subdirs [dir]/HASH and
-[dir]/HASH with OpenSSL hash filenames (e.g. 0d5fbbf1.0)
-symlinks pointing up to the corresponding *.crt file.
-([dir] is ~/.vnc/certs or one given by \fB-ssldir.)\fR
-This is a useful way for other OpenSSL applications
-(e.g. stunnel) to access all of the certs without
-having to concatenate them.  x11vnc will not use them
-unless you specifically reference them.  "HASHOFF"
-removes these HASH subdirs.
-.IP
-The LIST, LISTL, LL, ALL, HASHON, HASHOFF words can
-also be lowercase, e.g. "list".
-.PP
-\fB-sslDelCert\fR \fI[pem]\fR
-.IP
-Prompts you to delete all .crt .pem .key .req files
-associated with [pem].  "SAVE" and lookups as in
-\fB-sslCertInfo\fR apply as well.
-.PP
-\fB-stunnel\fR \fI[pem]\fR
-.IP
-Use the 
-.IR stunnel (8)
-(www.stunnel.org) to provide an
-encrypted SSL tunnel between viewers and x11vnc.
-.IP
-This external tunnel method was implemented prior to the
-integrated \fB-ssl\fR encryption described above.  It still
-works well.  This requires stunnel to be installed
-on the system and available via PATH (n.b. stunnel is
-often installed in sbin directories).  Version 4.x of
-stunnel is assumed (but see \fB-stunnel3\fR below.)
-.IP
-[pem] is optional, use "\fB-stunnel\fR \fI/path/to/stunnel.pem\fR"
-to specify a PEM certificate file to pass to stunnel.
-Whether one is needed or not depends on your stunnel
-configuration.  stunnel often generates one at install
-time.  See the stunnel documentation for details.
-.IP
-stunnel is started up as a child process of x11vnc and
-any SSL connections stunnel receives are decrypted and
-sent to x11vnc over a local socket.  The strings
-"The SSL VNC desktop is ..." and "SSLPORT=..."
-are printed out at startup to indicate this.
-.IP
-The \fB-localhost\fR option is enforced by default
-to avoid people routing around the SSL channel.
-Set STUNNEL_DISABLE_LOCALHOST=1 before starting x11vnc
-to disable the requirement.
-.IP
-Your VNC viewer will also need to be able to connect via
-SSL.  Unfortunately not too many do this.  UltraVNC has
-an encryption plugin but it does not seem to be SSL.
-.IP
-Also, in the x11vnc distribution, a patched TightVNC
-Java applet is provided in classes/ssl that does SSL
-connections (only).
-.IP
-It is also not too difficult to set up an stunnel or
-other SSL tunnel on the viewer side.  A simple example
-on Unix using stunnel 3.x is:
-.IP
-% stunnel \fB-c\fR \fB-d\fR localhost:5901 \fB-r\fR remotehost:5900
-% vncviewer localhost:1
-.IP
-For Windows, stunnel has been ported to it and there
-are probably other such tools available.  See the FAQ
-for more examples.
-.PP
-\fB-stunnel3\fR \fI[pem]\fR
-.IP
-Use version 3.x stunnel command line syntax instead of
-version 4.x
-.PP
-\fB-https\fR \fI[port]\fR
-.IP
-Choose a separate HTTPS port (-ssl mode only).
-.IP
-In \fB-ssl\fR mode, it turns out you can use the
-single VNC port (e.g. 5900) for both VNC and HTTPS
-connections. (HTTPS is used to retrieve a SSL-aware
-VncViewer.jar applet that is provided with x11vnc).
-Since both use SSL the implementation was extended to
-detect if HTTP traffic (i.e. GET) is taking place and
-handle it accordingly.  The URL would be, e.g.:
-.IP
-https://mymachine.org:5900/
-.IP
-This is convenient for firewalls, etc, because only one
-port needs to be allowed in.  However, this heuristic
-adds a few seconds delay to each connection and can be
-unreliable (especially if the user takes much time to
-ponder the Certificate dialogs in his browser, Java VM,
-or VNC Viewer applet.  That's right 3 separate "Are
-you sure you want to connect" dialogs!)
-.IP
-So use the \fB-https\fR option to provide a separate, more
-reliable HTTPS port that x11vnc will listen on.  If
-[port] is not provided (or is 0), one is autoselected.
-The URL to use is printed out at startup.
-.IP
-The SSL Java applet directory is specified via the
-\fB-httpdir\fR option.  If not supplied it will try to guess
-the directory as though the \fB-http\fR option was supplied.
-.PP
 \fB-usepw\fR
 .IP
 If no other password method was supplied on the command

x11vnc/x11vnc.h

@@ -119,6 +119,7 @@
 #endif
 
 #define noREL8x
+#define REL8x
 
 /*
  * Beginning of support for small binary footprint build for embedded

x11vnc/x11vnc_defs.c

@@ -15,7 +15,7 @@ int xtrap_base_event_type = 0;
 int xdamage_base_event_type = 0;
 
 /*               date +'lastmod: %Y-%m-%d' */
-char lastmod[] = "0.8.2 lastmod: 2006-07-11";
+char lastmod[] = "0.8.2 lastmod: 2006-07-12";
 
 /* X display info */