SSLD - The SSL Daemon

ssld is a daemon that can serve as an ssl proxy for non-ssl aware tcp based applications. ssld will connect securely to an ssl-aware server on behalf of a non-ssl client, and can accept secure connections from ssl based clients on behalf of a non-secure server. Two ssld processes can be used to set up a secure communications channel between two non-secure processes.

Running ssld

The command syntax for ssld is:

ssld-* [-i] [-D] [-d keydir] [-c conffile] [-C chrootdir]

where * is one of us or ex to specify using the domestic or international versions, respectively.

The -i option causes ssld to run in interactive mode. If this option is not specified ssld will fork.

The -D option enables debugging messages. It also enables interactive mode, just as -i does.

The -d option tells ssld to read key and certificate files from the directory keydir. The default directory is /usr/etc/ssl. The encrypted key database is named key.db, and the certificate database is cert.db. The name index for the certificate database is cert-nameidx.db. If you set an environment variable SSL_DIR to a directory path, ssld will search there. The -d option overrides this variable.

The -c option indicates that conffile should be used as the ssld configuration file. The default configuration file is ssld.conf. You may also set an environment variable SSLD_CONF to avoid specifying this option at the command line. The -c option overrides this variable. If the configuration filename begins with a '/', it is assumed to be a full pathname. Otherwise, the configuration file is searched for in the whatever directory is specified with -d or SSL_DIR (the default being /usr/etc/ssl).

The -C option causes ssld to change its root directory to chrootdir via the chroot(2) system call.

The ssld Configuration File

The ssld configuration file contains one line per port that it will listen on. Each line contains six entries. They are port, mode, acl, keyname, certname, and action.

The port is the port number or service name that can be looked up by getservbyname(3), of a port that ssld will listen on.

The mode field indicates to ssld how to treat a connection once it is made. There are four valid values for mode, which are client, server, auth-client, and auth-server. The meaning of the modes is as follows:

client (BROKEN)
The incoming connection is in the clear, and the forwarding connection will use SSL. ssld will perform the ssl handshake as a client.
auth-client (BROKEN)
Same as client except that the ssl handshake will include client authentication using ssld's certificate.
server
The incoming connection uses SSL. ssld will talk to the forwarding destination or exec'd daemon in the clear. ssld will perform the ssl handshake as a server.
auth-server
Same as server except that the ssl handshake will require the client to authenticate itself.

The acl field can either be the name of a file containing an access control list for this port, or a '-' indicating that there is no access control on this port. NOTE: Access control lists only work in auth-server mode. The access control list file contains a list of names, one per line. One of these names must match the common name field of the subject of the client's certificate. If no match is found then ssld will drop the connection.

The keyname field should be the nickname of the key that is accessed from the key.db database located in the directory specified with the -d option or the SSL_DIR environment variable.

The certname field should be the nickname of the certificate that is accessed from the cert.db database, always located in the same directory as key.db.

The action consists of a keyword, followed by an argument list. The two possible keywords are forward and exec.

The argument to forward is a host:port string, where host a hostname or ip address, and port is a port number or service name. ssld will connect to the given port on the given host, and forward all data from the incoming connection to that port, performing the appropriate ssl transformations based on the mode.

The arguments to exec are the pathname of the program to execute, followed by the name of the program and its arguments. The program is run with the socket of the incoming connection cloned onto its stdin, stdout, and stderr file descriptors, just like inetd. In addition, there is another socketpair created, one end of which is connected to file descriptor #3 of the exec'd program. This socket is used to provide a control channel between ssld and the exec'd program. It allows the exec'd program to create its own connections back through ssld. This is used by rshd. See sslref/contrib/rshd/rshd.c and sslref/src/libutil/ssld_util.c for details of how to use this facility.

Notes on Security

It is important to take some care in configuring ssld. A careless configuration could open some serious security holes. Some things to look out for: