Add the "socks_ssl" protocol, it secures the remote connection instead of the local connection #8
Right now stunnel can't be used as a socks server to reach TLS-only endpoints. For example, using this config file:
and simulating a non-TLS capable system as follows:
then I would expect to receive the home page of the site, but what I get instead is
This defeats the whole purpose of stunnel, which is "to add TLS encryption functionality to existing clients and servers without any changes in the programs' code", for the cases where we need to run it in socks server mode.
The proper fix for this would be to secure both the local and the remote connection, but this would require to manage two ssl endpoints where the application is currently designed for only one. Instead, I decided to implement a simpler workaround: using plain TCP for the socks negotiation and TLS for connecting to the target hosts, thus "reversing" the current behavior.
I have done this by adding a new protocol, named
...and then the
Some context on why this is needed
I'm a big fan of MSX computers. Many years ago another enthusiast of the platform developed ObsoNET, a network card for these computers; and I developed InterNestor, the TCP/IP stack to make the most of it.
Implementing TLS in InterNestor is out of the question because a Z80 can't handle the required encryption algorithms, so running stunnel on another computer (or even a Raspberry Pi) in the same network is a great alternative for connecting to TLS-only services. However, having to configure a client endpoint for each service is somewhat cumbersome, so my plan is to add socks client capabilities to InterNestor and then use stunnel as a socks server... but for that to work I need stunnel to TLS-ify the remote connection when running as such.
Error reporting after arm-linux-gcc cross-compilation
[!] error queue: ec_curve.c:3179: error:100AE081:elliptic curve routines:EC_GROUP_new_by_curve_name:unknown group