Back when Apple's Mail on a more outdated OS X setup stopped to be able to connect to various mail servers because of Apple's own outdated SSL/TLS implementation (security.framework?) I just plugged stunnel in the middle to make things work again: Mail connects to localhost and stunnel then safely connects to the remote mail server.
While this was an important fix at that time it also provided surprisingly additional benefits. Now it was much easier to entirely block outgoing connections from Mail with Little Snitch. Instead having numerous allow directives per mailserver, just one full block. E.g. no more random config changes that break everything, because Apple decided to push some auto-config changes for well-known mail providers. No more accidental tracking pixel triggers. Also all the accounts are now just vanilla POP3/SMTP accounts rather than those with "special handling". Finally Mail became much more stable for some reason. No more long lockups when I want to open the Account settings, no more random lockups when launching the app, etc.
Now I really do not want to miss this extra layer anymore because all the bonus benefits (even if it shouldn't be needed any longer just to make SSL/TLS work again).
Over time bunch of other things (Mail unrelated) got plugged into the stunnel config too. :)
https://www.linuxjournal.com/content/encrypting-nfsv4-stunne...
RFC-9289: Towards Remote Procedure Call Encryption
“Special mention goes to Charles Fisher, author of ‘Encrypting NFSv4 with Stunnel TLS’ [LJNL]. His article inspired the mechanism described in this document.”
I know stunnel serves different purpose, but still why would you need it for your service if you can be in the vpn and speak plaintext?
I always considered it the best solution to have both: VPN encryption and TLS encryption over the VPN. Different OSI Layers. Different Attack Surfaces.
Not sure if that is a recommended pratice though (see initial remark ;) )
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.
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.
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've found stunnel a godsend for bridging the gap. Granted, I am more of a sysadmin-ey type where a few times I've had to abruptly/quickly get something up and running.
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.
I know I'm somewhat blind to jargon, but that seems fairly straightforward?