stunnel icon indicating copy to clipboard operation
stunnel copied to clipboard

Add the "socks_ssl" protocol, it secures the remote connection instead of the local connection

Open Konamiman opened this issue 5 years ago • 2 comments

Right now stunnel can't be used as a socks server to reach TLS-only endpoints. For example, using this config file:

[socks_server]
protocol = socks
accept = 1081
PSKsecrets = stunnel.secrets

[socks_client]
client = yes
accept = 1080
connect =  localhost:1081
PSKSecrets = stunnel.secrets

and simulating a non-TLS capable system as follows:

curl --proxy "socks4://localhost:1080" "http://www.konamiman.com:443"

then I would expect to receive the home page of the site, but what I get instead is 400 The plain HTTP request was sent to HTTPS port. That's because when runing as a socks server stunnel uses TLS to secure the local connection, but the connection to the target endpoint is made in plain TCP.

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 socks_ssl (suggestions for a better name welcome), so that you can use this configuration:

[socks_ssl_server]
protocol = socks_ssl
accept = 1080
PSKsecrets = stunnel.secrets

...and then the curl example above will work as expected, retrieving the contents of the page.

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.

image

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.

Konamiman avatar Jul 12 '19 05:07 Konamiman

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 [!] error queue: ec_curve.c:3126: error:100AF010:elliptic curve routines:EC_GROUP_NEW_FROM_DATA:EC lib [!] EC_KEY_new_by_curve_name: bn_gcd.c:525: error:0306E06C:bignum routines:BN_mod_inverse:no inverse [.] Configuration successful [ ] Binding service [rtsp] [ ] Listening file descriptor created (FD=9) [ ] Setting accept socket options (FD=9) [ ] Option SO_REUSEADDR set on accept socket [ ] Service [rtsp] (FD=9) bound to 0.0.0.0:443 [!] Cannot open log file: /var/log/stunnel.log [ ] Deallocating section defaults

lilei-John avatar Oct 09 '19 09:10 lilei-John

I need the same feature, please commit this fix.

itamarjp avatar Feb 05 '22 03:02 itamarjp