The Geeks Corner

Let’s say that we want to run SSL-enabled POP3 on the standard port for this (995). If we already
have the unencrypted POP3 server running on port 110, we simply put Stunnel on port 995, and
tell it to forward connections to port 110 on the loopback interface (so that unencrypted data isn’t
sent over your local network, just to come back onto the current machine). When SSL-enabled
POP3 clients connect to port 995, Stunnel will negotiate the connection, connect itself to the POP3
port, then start decrypting data. When it has data to pass on to the POP3 server, it does so.
Similarly, when the POP3 server responds to a client request, it talks with the Stunnel proxy,
which encrypts the response, and passes it on to the client. See Figure 1-5 for a graphical overview of the process.

To use Stunnel on the server side, you must install a valid server certificate and private key. An
appropriate Certification Authority should sign the certificate. You can generate your own
credentials using OpenSSL. That process is covered in Chapter 3.
These server credentials will need to be made available to Stunnel. Often, the correct location of
these credentials will be hardcoded into the Stunnel binary. If not, you can specify their location
on the command line.
Assuming the POP3 server is already running, here is how you would run Stunnel from the
command line to implement the above scenario (assuming that you’re running as root, which is
necessary for binding to low ports on Unix machines):

stunnel -d 995 -r 127.0.0.1:110

The -d flag specifies that Stunnel should run as a proxy in daemon mode on the specified port
(you can also specify the IP address on which to bind; the default is all IPs on the machine). The –
r flag specifies the location of the service to which Stunnel will proxy. In this case, we
specifically mention the loopback address to avoid exposing unencrypted traffic to other hosts on
the same local network. Optionally, we could hide the port from external eyes using a firewall.
The location of the certificate file can be specified with the -p flag, if necessary. If your machine’s
services file contains entries for the POP3 and the Secure POP3 protocol, you can also run Stunnel like this:

stunnel -d pop3s -r 127.0.0.1:pop3

You can also run Stunnel from inetd. However, this is generally not desirable, because you forego
the efficiency benefits of session caching. If you’re running on Windows, Stunnel is available as a
precompiled binary, and can be easily launched from a DOS-style batch file. See the Stunnel FAQ
(http://www.stunnel.org/faq) for more details.
Unfortunately, Stunnel can’t protect all the services you might want to run. First, it can protect
only TCP connections, not UDP connections. Second, it can’t really protect protocols like FTP that
use out-of-band connections. The FTP daemon can bind to arbitrary ports, and there’s no good
way to have Stunnel detect it. Also, note that some clients that support SSL-enabled versions of a
protocol will expect to negotiate SSL as an option. In such cases, the client won’t be able to
communicate with the Stunnel proxy, unless it goes through an SSL proxy on the client end as
well.
Since Stunnel will proxy to whatever address you tell it to use, you can certainly proxy to services
running on other machines. You can use this ability to offload the cost of establishing SSL
connections to a machine by itself, providing a cost-effective way of accelerating SSL. In such a
scenario, the unencrypted server should be connected only to the SSL proxy by a crossover cable,
and should be connected to no other machines. That way, the unencrypted data won’t be visible to
other machines on your network, even if they are compromised. If you have a load balancer, you
can handle even more SSL connections by installing additional proxies (see Figure 1-6). For most
applications, a single server is sufficient to handle the unencrypted load.

Figure 1-6. Load balancing with Stunnel for cryptographic acceleration

The biggest problem with using Stunnel as a proxy is that IP header information that would
normally be available to the server isn’t. In particular, the server may log IP addresses with each
transaction. Since the server is actually talking to the proxy, from the server’s point of view, every
single connection will appear to come from the proxy’s IP address. Stunnel provides a limited
solution to this problem. If the secure port is on a Linux machine, then the Stunnel process can be
configured to rewrite the IP headers, thus providing transparent proxying. Simply adding the -T
flag to the command line does this. For transparent proxying to work this way, the client’s default
route to the unencrypted server must go through the proxy machine, and the route cannot go
through the loopback interface.
Stunnel can be configured to log connections to a file by specifying the -o flag and a filename.
That at least allows you to get information about connecting IP addresses (which should never be

used for security purposes anyway, since they are easy to forge), even when transparent proxying
is not an option.

---

Published @ January 5, 2022 9:39 am