Description
Some service you depend on only speaks plaintext: an internal database port, a vendor API, the POP3 port on the mail server. Getting it encrypted usually means waiting on the vendor to change their code, or standing up a reverse proxy and configuring the whole thing. Stunnel takes the blunt route — it wraps TLS around the program from the outside, with not a line of that program changed. You just state which port to listen on, where to forward, and which certificate to use.
The configuration is a single stunnel.conf: a few lines per section, one section per tunnel. Copy that file to the next machine and the same setup is live, with no clicking through a GUI again. Underneath it is OpenSSL, so the serious parts are all there — forward secrecy, OCSP and CRL revocation checks, chain verification, hostname checking — each a single line in the file.
Client and server modes: the same binary encrypts outbound traffic for a local plaintext program (client = yes) or terminates TLS in front of a backend, so one section at each end gives you a complete encrypted path.
Driven purely by config: a [name] header plus accept and connect defines a tunnel, and the bundled sample already ships working POP3, IMAP and SMTP sections for Gmail to copy from.
Certificate checking in detail: verifyChain walks the whole chain, checkHost matches the name on the certificate, OCSPaia turns on live revocation lookups, and CRL files are supported — so a revoked certificate does not quietly get trusted.
Perfect forward secrecy: session keys are decoupled from the server's long-term private key, so traffic captured today stays unreadable even if that key leaks later.
Pre-shared keys: in a controlled environment you can skip certificates entirely and put the same PSK on both ends instead of running a CA.
A log window on Windows: it sits in the tray, and opening the window shows every configuration load, handshake and connection; reload the config from the menu without restarting the service.
Several backends per tunnel: connect accepts more than one address and spreads connections across them, which covers simple distribution without a separate load balancer.
The configuration is a single stunnel.conf: a few lines per section, one section per tunnel. Copy that file to the next machine and the same setup is live, with no clicking through a GUI again. Underneath it is OpenSSL, so the serious parts are all there — forward secrecy, OCSP and CRL revocation checks, chain verification, hostname checking — each a single line in the file.
Features
Client and server modes: the same binary encrypts outbound traffic for a local plaintext program (client = yes) or terminates TLS in front of a backend, so one section at each end gives you a complete encrypted path.
Driven purely by config: a [name] header plus accept and connect defines a tunnel, and the bundled sample already ships working POP3, IMAP and SMTP sections for Gmail to copy from.
Certificate checking in detail: verifyChain walks the whole chain, checkHost matches the name on the certificate, OCSPaia turns on live revocation lookups, and CRL files are supported — so a revoked certificate does not quietly get trusted.
Perfect forward secrecy: session keys are decoupled from the server's long-term private key, so traffic captured today stays unreadable even if that key leaks later.
Pre-shared keys: in a controlled environment you can skip certificates entirely and put the same PSK on both ends instead of running a CA.
A log window on Windows: it sits in the tray, and opening the window shows every configuration load, handshake and connection; reload the config from the menu without restarting the service.
Several backends per tunnel: connect accepts more than one address and spreads connections across them, which covers simple distribution without a separate load balancer.
