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@stunnel.org] On Behalf Of mihertz@gmx.de Sent: Tuesday, June 18, 2019 11:19 PM To: stunnel-users@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@stunnel.org https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users