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.”
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. :)
To add on to this, in some organizations it's easier to assess risk according to RMF and similar frameworks if the application ships with stunnel and is configured from within than it is for the application to require a system-level VPN like Wireguard.
That said, I think Wireguard is easier to analyze on the wire since it has a known binary signature from the first 4 bytes, while stunnel tunnel is indifferentiable from web browsing traffic. For a bad actor looking into exfil or C2, this means an stunnel is probably the sneakier and thus more reliable method of encryption on the wire compared to wireguard.
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.
I was involved in a very similar situation once.
I recommend wireguard for this, it's mature for years, has superb support in linux and some BSDs and there are userspace implementations if you need that.
It wraps traffic in UDP, the overhead is much smaller thus throughput mich higher than traditional TCP-based VPN (you want to avoid tcp-in-tcp!).
There were once patches posted to lkml that passed QoS-flags from the inner packet to the wireguard packet, if you need that. not sure if that landed upstream in the end.
key distribution and lifecycle management is what was still unsolved years back when this was evaluated, nowadays tailscale and its clones and similar oss should serve you well.
"Everyday you get electricity, water, transportation, food, and general survival are dependant on horrifically outdated software systems that aren't going to be changed any time soon"
I mean...fair. All I can say is it's still very critical and in production. I guess it's just worth pointing out that horribly outdated things still need support :)
Maybe they need something that works without root and IP space allocation. I like WireGuard and use it myself but it is a bit of an installation compared to binding a port
Not a security expert and also curious about implications:
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 ;) )
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.
same here. This thing is gold for "80% solutions" in that respect. It's easier to sanely integrate with legacy transport protocols than trying to update the legacy code base to implement mutual trust the harder, more direct and more error-prone way, IMO.
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.
As someone that has built security applications for most of this century, I can confidently say that when you make security the problem of one device, system, team or entity that it results in insecurity. It might satisfy some auditors but that’s about it.
The most obvious issue is that if any system is compromised, then the attacker can potentially sniff traffic and they are all effectively compromised. The next one, and it’s really key to TLS, is that the app you are proxying probably has an opinion or desired behavior when things can’t be authenticated or are improper. Someone reading you blog and the cert is a day old? Probably not super risky to let them read it. Logging in to the mail server and the keys are bad? You might want the server to just block that.
For like a home lab situation or kind of toy systems? These tools are great, I’ve used stunned more than a few times to hack things together
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.
Right! That, or I otherwise encounter some kind of asymmetry where one side, whether it is a client or server, implements/requires speaking TLS whereas the otherside isn't readily equipped to do so.
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.
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.
NFSv4 over stunnel, by yours truly.
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.”
https://www.rfc-editor.org/info/rfc9289
Stunnel is an important part of my setup here.
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. :)
Wireguard is the best (I find its great performance an order of magnitude better than tunelling via ssh for example).
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?
stunnel is often easier to embed directly into client applications, whereas WireGuard is better suited as a system-level VPN.
To add on to this, in some organizations it's easier to assess risk according to RMF and similar frameworks if the application ships with stunnel and is configured from within than it is for the application to require a system-level VPN like Wireguard.
That said, I think Wireguard is easier to analyze on the wire since it has a known binary signature from the first 4 bytes, while stunnel tunnel is indifferentiable from web browsing traffic. For a bad actor looking into exfil or C2, this means an stunnel is probably the sneakier and thus more reliable method of encryption on the wire compared to wireguard.
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.
Is there anything that isn't horribly outdated that still needs this?
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.
I was involved in a very similar situation once. I recommend wireguard for this, it's mature for years, has superb support in linux and some BSDs and there are userspace implementations if you need that. It wraps traffic in UDP, the overhead is much smaller thus throughput mich higher than traditional TCP-based VPN (you want to avoid tcp-in-tcp!). There were once patches posted to lkml that passed QoS-flags from the inner packet to the wireguard packet, if you need that. not sure if that landed upstream in the end. key distribution and lifecycle management is what was still unsolved years back when this was evaluated, nowadays tailscale and its clones and similar oss should serve you well.
This is cool, but "legacy systems that talk over TCP in plaintext" sounds like it might qualify for "horribly outdated", no?
A different way to think of this is...
"Everyday you get electricity, water, transportation, food, and general survival are dependant on horrifically outdated software systems that aren't going to be changed any time soon"
I mean...fair. All I can say is it's still very critical and in production. I guess it's just worth pointing out that horribly outdated things still need support :)
Not wireguard?
Maybe they need something that works without root and IP space allocation. I like WireGuard and use it myself but it is a bit of an installation compared to binding a port
Not a security expert and also curious about implications:
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 ;) )
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.
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.
same here. This thing is gold for "80% solutions" in that respect. It's easier to sanely integrate with legacy transport protocols than trying to update the legacy code base to implement mutual trust the harder, more direct and more error-prone way, IMO.
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.
As someone that has built security applications for most of this century, I can confidently say that when you make security the problem of one device, system, team or entity that it results in insecurity. It might satisfy some auditors but that’s about it.
The most obvious issue is that if any system is compromised, then the attacker can potentially sniff traffic and they are all effectively compromised. The next one, and it’s really key to TLS, is that the app you are proxying probably has an opinion or desired behavior when things can’t be authenticated or are improper. Someone reading you blog and the cert is a day old? Probably not super risky to let them read it. Logging in to the mail server and the keys are bad? You might want the server to just block that.
For like a home lab situation or kind of toy systems? These tools are great, I’ve used stunned more than a few times to hack things together
I use Caddy the same way. My web apps aren't allowed to think about TLS, they sit behind Caddy and I'm secure as long as I keep it updated
That's basically the idea behind zero trust, isn't it? The idea being that you can't even knock on the TCP port if you're not authenticated
Let me introduce you to software for public library information systems that still thinks it's the 90s!
wrapping z39.50?
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 use it to wrap my gstreamer tcp streams in TLS to send them over the internet, but socat can also do the same thing.
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.
I used it once with althttpd. https://sqlite.org/althttpd/doc/trunk/althttpd.md
Another Althttpd user here. Being able to write a "microservice" just by making a file executable is awesome.
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.
Right! That, or I otherwise encounter some kind of asymmetry where one side, whether it is a client or server, implements/requires speaking TLS whereas the otherside isn't readily equipped to do so.
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.
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 what?
> 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]