Skip to content


Switch branches/tags

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

Latest commit


Git stats


Failed to load latest commit information.
Latest commit message
Commit time
General information

The Symbion SSL Proxy is a network server application. It listens on a TCP
port, accepts SSL connections, and forwards them to an other (local or remote)
TCP port, or UNIX domain socket.
It is NOT a HTTPS server itself, but it can act as a HTTPS server, if you run
an SSL Proxy server on port 443 which forwards the connections to port 80.
SSL Proxy is tested with HTTP, but it should work with any SSL protocols, I

SSL Proxy was developed with security in mind. When it allocated the server
TCP port and loaded everything from the filesystem, it chroot()s to a
(possibly empty) directory and changes the process's real and effective user
id to a specified user.

Make sure you have installed OpenSSL, than run make in the main directory.
Copy ssl_proxy to anywhere you want :)

Key generation
SSL Proxy can not generate keys, use ssleay's req utility to do it:
	# mkdir /etc/symbion; cd /etc/symbion
	# openssl req -days 365 -nodes -new -x509 -out cert.pem -keyout key.pem
	# chmod go-rwx key.pem

SSL Proxy does not has a config file, it simply has some command line
    General options:
	-h			Usage information.
	-d			Turn on debugging. SSL Proxy will not go into
				the background and it will print a lot of
				debug information to stderr.
	-f			Do not detach from the terminal and run in the
				forground. Useful if you want to run SSL Proxy
				from Symbion Daemon Tool.
	-i			Provide some info to the server about the
				client (see below)
	-s [<server host>:]<server port>
				Specify the port, which SSL Proxy will listen
				on (or address to bind to a specific interface).
	-c [<client host>:]<client port>
				Specify the TCP port, which SSL Proxy will
				connect to as a client (The forwarding port).
	-c unix:<socket path>
				Specify the UNIX domain socket, which SSL Proxy
				will connect to as a client (The forwarding port).
	-m <max connection>	SSL Proxy will accept maximum this number of
    SSL options:
	-C <certificate file>	SSL Public Certificate file (see Key generation).
	-K <key file>		SSL Private Key File (see Key generation).
	-p <cipher list>	SSL cipher list
    Security options:
	-u <user/uid>		Change real and effective UID to this after
	-r <chroot dir>		Chroot to the specified directory after
    Buffer size options:
	-U <upward buffer>	The size of the buffer used for
				client -> server data transfer.
	-D <downward buffer>	The size of the buffer used for
				server -> client data transfer.
    # ssl_proxy -s 443 -c localhost:80 -m 32 -C /etc/symbion/cert.pem \
	    -K /etc/symbion/key.pem -U 2048 -D 8192

SSL Proxy 1.0.0 introduced the ability to connect to UNIX domain sockets, not
just TCP sockets. Please note that if you use UNIX domain sockets and you also
use the -r (chroot) feature to make your system more secure, than the socket
file must reside under the chrooted directory. The path specified in the -c
option must be relative to the chrooted directory.
Also note that if you use UNIX domain sockets with the -u (setuid) feature,
then the user must have read and write permission to the socket file.
The TCP sockets has no similar limitations, because they are not associated
with filesystem objects.

The file provided with the -v option can contain several CA certificates in
PEM format. If you use the -V (certificate directory) option, then each file
have to contain exactly ONE certificate. The files are looked up by the CA
subject name hash value, which must be available. You can create symlinks with
the c_rehash utility, contained in the openssl package.

Client info feature
SSL Proxy can provide client information to the server in a special format.

This is a new feature in version 1.0.7, so I do not know of any server software
that can use this information except my own special purpose software. If I
receive information about any software available that uses this information, I
will publicate it on our website,

The usage is very simple. You provide the -i option to SSL Proxy. When a
client connects, SSL Proxy connects to the server the usual way. But before
the data sent by the client is forwarded to the server, SSL Proxy sends an
information line to the server. This is an example of a HTTPS connection with
the -i option:

szilu@maia:[~]$ nc -l -p 8080
#@ip= port=57223
GET / HTTP/1.1
Host: localhost:8443
User-Agent: Links (2.1pre37; Linux 2.6.27-11-eeepc i686; 80x24)
Accept: */*
Accept-Encoding: gzip, deflate

As you can see, an extra line beginning with '#@' is sent to the server. It
contains the IP address and the TCP port of the client and optionally the
common name (cn) of the client, if it has provided a certificate.

This information can be used for example for logging or access control purposes.

If you are running a HTTP server at port 80 which does not has SSL support,
and you want it to work on SSL too, than defaults are good for you:
	# ssl_proxy
If you would like to use maximal security level, you can use:
	# mkdir /etc/symbion/chroot_dir
	# ssl_proxy -u nobody -r /etc/symbion/chroot_dir

How to report bugs
To report a bug, send mail to
In the mail include:

* The version

* Information about your system. For instance:

    - What operating system and version
    - What version of OpenSSL
    - What version of the C library

  And anything else you think is relevant.

* How to reproduce the bug. 

* The text that was printed out (Debug information).

You can also use tha SourceForge bugtracking system at


Patches can be sent to tha mailing list.
Please include your name and email address.

If the patch fixes a bug, it is usually a good idea to include
all the information described in "How to Report Bugs".

    Szilard Hajba <>


SSL forwarding proxy server







No releases published


No packages published