[stunnel-users] stunnel client: accept on connect success

Wed Jun 19 19:08:58 CEST 2019

I'm a dummy so what I do is write a "wrapper" -- you connect to your wrapper
and manage your problem.  If all is good exec stunnel.  If not send
appropriate messages back. 

Dummy idea,

Eric

-----Original Message-----
From: stunnel-users [mailto:stunnel-users-bounces at stunnel.org] On Behalf Of
mihertz at gmx.de
Sent: Tuesday, June 18, 2019 11:19 PM
To: stunnel-users at stunnel.org
Subject: [stunnel-users] stunnel client: accept on connect success

Hi everyone,

could use some help for a stunnel client-mode question.

Found no corresponding config directives in the manpage, not sure i am
searching with the correct terms... or going for the correct approach at
all.

So there is a scenario where the stunnel client plaintext side does the
tcp-handshake (S/S./.) and directly terminates the connected client
afterwards (R.). This is caused because the corresponding connect-target
fails to establish a TCP/TLS connection with the server (rejected by target
server for whatever reason).

This could cause a first regular tcp-packet to be send and lost, before
stunnel disconnects on the plaintext-side and the application becomes aware
of that eventually.

I wonder if there is a way to configure stunnel to behave in a similar way
to haproxy /w acl? Where it denies all tcp connects unless at least
1 backend server is available.

So that stunnel would like "delay" the accept-side TCP handshake while
trying to connect to the connect-side via TLS. Based on TCP/TLS
success/failure on the connect-side then continues the accept-side TCP
handshake or quits its. This way the client would never have the short
moment of "ok, i can start"

I know that this behaviour is not optimal/desired with the majority of
cases, just have the impression I have a use-case for this in my scenario.
There is no way to modify the plaintext-side connected application in any
way. Tx/Rx data is just a few bytes, so its always 1 packet for
requests/answers.
And relatively often that first packet sent goes out before the reset
(R.) is received by the stunnel client-mode to the software connected on the
accept-side.

Would be happy for your input and ideas on how to work around that.

Best Regards
Michael
_______________________________________________
stunnel-users mailing list
stunnel-users at stunnel.org
https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users