stunnel is often easier to embed directly into client applications, whereas WireGuard is better suited as a system-level VPN.

I only use it for shell access to machines in my home network, so I cannot remark on performance, but it is also by far the easiest to use VPN solution I've had contact with. Not that I'm an expert in this matter, but setting up Wireguard access was dead simple and it has never given me any trouble since.

No joke, it just came up at work as a possible solution to something. We have some legacy systems that talk over TCP in plaintext. It's all within well-secured networks on locked down machines, so fine. But now we want to move things to Megaport, and their agreement says "btw don't put anything in plaintext ever, we guarantee nothing". So stunnel will probably be the fix.

The company I work for has used it as a relatively simple method for implementing mutual TLS (mTLS) for legacy apps or systems for which it would otherwise be annoying or more difficult to integrate mTLS for, or which doesn’t support mTLS with custom trust store.

Let me introduce you to software for public library information systems that still thinks it's the 90s!

Stunnel basically allows you to easily secure existing network protocols.

POP3 over stunnel -> SPOP3.

A practical solution, both for legacy components and for the cases when you don't want to deal with implementing TLS natively.

Ultimately, it's very Unix in spirit. Does one specific thing and is composable with others.

Hmmm... Got me thinking, why must all software implement (and maintain) transport security?

The security standard changes/improves over time. With software like stunnel takes care of it, your software could be practically security wise up-to-day forever as long as you or your user keeps their stunnel updated.

If you want an encrypted tunnel maintained by inetd or systemd socket activation, then stunnel is easier to use in this context than ssh.

Edit: I put stunnel on port 443 and have it connect to port 80 on my Apache webservers, because I like one way of doing TLS.

This guide has been useful for many years in cipher selection:

https://hynek.me/articles/hardening-your-web-servers-ssl-cip...

I mean, most web application backends don't implement TLS at all, under the assumption that you're using it alongside a reverse proxy. Most of the time this is nginx, but if you want to ensure no bugs are introduced on the HTTP level by the reverse proxy, stunnel is a perfectly fine option.

I used it once with althttpd. https://sqlite.org/althttpd/doc/trunk/althttpd.md

I use it to wrap my gstreamer tcp streams in TLS to send them over the internet, but socat can also do the same thing.

Allows me to speak SSL and receive mail. I like that. I sign up for a bunch of stuff that I want RSSified. I don’t want to implement SSL. This does the trick.

Is there any other way to do this?

Just slap an HTTPS proxy on top of an pure HTTP server. It's simpler to debug and understand.

Otherwise you need to learn how to slap SSL onto 10 different HTTP things.

> Stunnel is a proxy designed to add TLS encryption functionality to existing clients and servers without any changes in the programs' code.

I know I'm somewhat blind to jargon, but that seems fairly straightforward?

Stunning

[I’ll show myself out]