sslredir

NAME

SYNOPSIS

DESCRIPTION

sslredir is a simple utility used for redirecting incoming non-SSL connections to outgoing SSL connections. This is useful for enabling applications such as mail, news, or IRC clients, which do not support SSL, to connect to SSL servers. It also supports connecting to the remote host through a SOCKS4A proxy, so sslredir is ideal for use with Tor (http://tor.eff.org).

By default, sslredir will verify that the remote host's SSL certificate is signed by a known Certificate Authority (CA). This check can be disabled with the -n option. It will further verify that the specified host name (ssl_host) is the same as that specified by the Common Name field in the remote host's certificate. This check can be disabled with the -m option.

An additional verification can be performed by specifying the fingerprint of the remote host's certificate using the -f option. The fingerprint, as well as other information about the remote host's certificate, can be gotten with the -i option. (See EXAMPLES below.) This option is particularly useful if the remote host's SSL certificate is self-signed (i.e. it is not signed by a known CA) and you skip the signature check using -n, but you still want an assurance that you are not the victim of a Man in the Middle (MitM) attack. Obviously the manner in which you obtain the fingerprint becomes important. (After all, an attacker could substitute her own certificate at any time, including when you obtain the fingerprint with -i.)

Therefore, should you have the means, if the identity of the remote host has not been verified by a trusted Certificate Authority, you should obtain the fingerprint of the remote host by connecting from two or preferably three systems on different networks to provide a reasonable assurance that the fingerprint is genuine. Alternatively, you could contact the administrator of the remote site by some other medium (telephone, or previously verified PGP key) and ask for the fingerprint. In fact, even if the remote host's certificate is signed by a trusted CA, it doesn't hurt to use this option anyway. Extra paranoia never hurt anyone. (Except for crazy people.)

The fingerprint is simply the SHA-1 hex digest of the site's certificate in DER format. Given a PEM certificate, it can be gotten with this command:

openssl x509 -in cert.pem -outform der | sha1sum

sslredir will attempt to locate the CA certificate bundle on the system. If it cannot be found, it will be necessary to specify the file (probably called ca-bundle.crt) using the -c option. Otherwise, it will not be possible to verify the signature of the remote host's certificate.

Most common uses of sslredir will require specifying a port on which to listen using the -l option. Without this option, sslredir will automatically initiate a connection to the remote host and accept data on standard input. This can be useful for testing and debugging.  

OPTIONS

-l, --listen=port

Specify the port on which to accept incoming connections. Upon accepting a new connection, sslredir will initiate a new SSL connection to ssl_host. On connecting to the remote host, its SSL certificate will be checked for a valid signature, correct host name, and/or correct fingerprint. (See below for the options used to toggle these checks.) Only when the required checks pass will data be transferred between the incoming non-SSL and outgoing SSL connections. If any of the required checks fails, both connections will be immediately terminated.

-b, --bind=IP

By default, sslredir will accept connections (on the port specified by -l) only to localhost (127.0.0.1). Specifying an IP with -b will cause sslredir to accept connections only to this IP instead. An IP of 0.0.0.0 is a special value which tells sslredir to bind to all interfaces.

-s, --socks=host[:port]

Use the specified SOCKS server (SOCKS4A support required) for all outgoing connections. The port is optional, and if not specified will default to 1080. sslredir will also use the SOCKS4A server for resolving the hostname of the remote host.

-d, --daemonize

Causes sslredir to fork and run as a daemon. This option only makes sense when specifying a port with -l.

-m, --noverifyhost

By default, sslredir will check that the hostname specified in the Common Name (CN) field of the SSL certificate is the same as the hostname specified for ssl_host. This option will disable that check.

-n, --noverifyca

By default, sslredir will verify that the remote host's SSL certificate is signed by a known Certificate Authority. The file containing all known Certificate Authorities can be specified by the -c option, but sslredir will attempt to locate this file on its own. Disabling this check is not recommended, but may be necessary if the remote host is using a self-signed certificate. This option will disable signature verification.

-3, --sslv3

The default connection method for outgoing connections is TLSv1. This should work fine for most situations, but if you get a "wrong version number" error, try this option to force SSLv3.

-f, --fingerprint=hexdigest

Requires that the remote host's SSL certificate matches the given fingerprint. You can obtain the fingerprint by using the -i option. See DESCRIPTION above for more discussion on this feature.

-i, --info

Display information about the remote host's certificate. At the end of this output, sslredir will indicate whether the Certificate Authority's signature is valid (given the known CA certificates, which can be specified by the -c option), and it will also output the fingerprint of the remote host's certificate, which can be used with the -f option.

-x, --nosyslog

sslredir will by default log to the system log. This option will disable system logging.

-c, --cafile=file

Use the specified file for verifying the signature of the remote host's certificate. OpenSSL is distributed with a file called ca-bundle.crt which can be used here, although by default sslredir should be able to locate this file on most systems without specifying this option. Use this option to specify the path to the CA bundle if sslredir isn't able to find it. You might also want to use this option if the remote host uses a self-signed certificate and you have access to the signing certificate.

-r, --restart=size

Restart sslredir after RSS memory usage reaches size kilobytes. This feature is provided as a kludge to work around a memory leak in m2crypto. sslredir will not restart if there are currently active connections. Only likely to work on Linux.

-h, --help

Displays usage information and exits.

-v, --version

Displays version information and exits.

REQUIREMENTS

http://sandbox.rulemaker.net/ngps/m2/

M2Crypto may come packaged with your distribution. For example, on Fedora, try:

yum install m2crypto

EXAMPLES

Show information about the SSL certificate on irc.example.com:

sslredir -i irc.example.com:ircs

Same as above, only do so using the Tor SOCKS4A proxy, which is running on the same machine as sslredir:

sslredir -i -s localhost:9050 irc.example.com:ircs

Accept connections on port 16667 and forward to irc.example.com:ircs:

sslredir -l 16667 irc.example.com:ircs

After seeing that the server's certificate is self-signed, and its fingerprint is 8e1193528c2b18525cb4315ff41d5075ac8cd3c4, accept incoming connections on port 16667 and forward to irc.example.com:ircs via the Tor SOCKS4A proxy server installed on the local machine. This will not try to verify the signature of the certificate, but it requires that the remote host's certificate matches the above fingerprint; sslredir will daemonize and run in the background:

sslredir -dnl 16667 -s localhost:9050 -f \

   8e1193528c2b18525cb4315ff41d5075ac8cd3c4 \

   irc.example.com:ircs

BUGS

This man page is nearly the same size as sslredir itself. This is surely a bug in the English language.

Send bug reports to <tack@sault.org>. Please make sure you have obtained the latest version from http://sault.org/  

LICENSE

SEE ALSO

openssl(1), stunnel(8), nc(1), socat(1), tor(1)  

AUTHOR

Index

NAME

SYNOPSIS

DESCRIPTION

OPTIONS

REQUIREMENTS

EXAMPLES

BUGS

LICENSE

SEE ALSO

AUTHOR