- stunnel-users - stunnel.org

hi
by fieldengineer59＠yahoo.com 04 Nov '20

04 Nov '20

hi

1 0

Stunnel failover
by Ray 02 Nov '20

02 Nov '20

Has anyone tested this scenario with a number of stunnel clients and servers chained in a row with failover capability. The problem is that Stunnel in server mode accepts a connection and performs the SSL handshake before it checks if the connect endpoint is reachable. This causes the downlink client peer wrongly assumes that the link is up and therefore would not try the alternative failover endpoint. You will only observe this problem if you cascade several nodes in a row Ex: Dummy TCP Client <-> Stunnel1 (client) <-> Stunnel2 (server) <-> Stunnel3 (client) <-> Dummy SSL Server In this scenario, dummy client connects to S1, S1 connects to S2 (SSL), S2 tries to connect to S3 but since Dummy SSL server is down, S3 rejects but this rejection is not bouncing back to Dummy Client because S2 has down the downlink handshake and therefore S1 assumes everything is OK. So, the ultimate question is how can we tell Stunnel to first try to connect to endpoints and then send a SYN-ACK back to downlink TCP connection request. This way, a client sends a SYN to Stunnel, Stunnel holds on 3-way handshake, tries to connect to the uplink and completes the downlink handshake only if the uplink connection is OK.

1 0

Stunnel - SSL socket error Connection timed out
by sravan kumar 22 Oct '20

22 Oct '20

Hi Team, Need help on one issue. We recently configured stunnel on our servers for securely establishing DB connections[certs exchanged on stunnel client and server]. Stunnel installed on client machine. Stunnel installed on server machine. Configurations are completed and publishing working for sometime like 1 hr. After that the stunnel on the destination server did not respond and we noticed "SSL socket error: Connection timed out (110)". We made updates to the stunnel.conf with below entries but they are not updating. TIMEOUTclose = 0 TIMEOUTconnect = 200 TIMEOUTidle = 86400 Any help would be greatly appreciated. Regards, Sravan

1 0

5.57 cb_new_auth
by duncan.morris＠cdl.co.uk 20 Oct '20

20 Oct '20

When compiling 5.57 against OpenSSL 1.0.2 I am getting compiler warnings for the cb_new_auth definition. ENGD20 is running V8.4 [840] on ALPHA Building with OpenSSL 1.0.2 Image : STUNNEL.HPE_ALPHA_EXE "session authenticated", cb_new_auth, NULL, NULL); .................................^ %CC-W-PTRMISMATCH, In this statement, the referenced type of the pointer value "cb_new_auth" is "function (pointer to void, pointer to void, pointer to struct crypto_ex_data_st, int, long, pointer to void) returning void", which is not compatible with "function (pointer to void, pointer to void, pointer to struct crypto_ex_data_st, int, long, pointer to void) returning int" . at line number 80 in file DISK$ORACLE:[STUNNEL_BUILDS.stunnel-557.src]ssl.c;1 This appears to be the result of OpenSSL 1.0.2 defining this as an integer function, whilst 1.1.1 defines it as a void function. Duncan

1 0

Changelog policy / watch out for 5.57 if you have 1024-bit keys in use
by ian.bamforth＠tracsis.com 20 Oct '20

20 Oct '20

Morning, [ ] Loading certificate from file: /opt/clients/certificate_2020-04-23.pem [!] SSL_CTX_use_certificate_chain_file: ssl/ssl_rsa.c:301: error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key too small [!] Service [RailCompanion]: Failed to initialize TLS context [!] Configuration failed We encountered a production outage yesterday when upgrading to 5.57, as it seems that a new securityLevel config has been added, a side-effect of which looks to have been the rejection of certificates of less than 2048 bits by default. We still had a 1024 bit cert in use. Obviously we should've had monitoring to check that stunnel was actually running (we will next time!) but it seems to me like this is a change that deserved more attention in the log, which only identifies it as a new feature, with no mention of breaking changes. Anyway, our problem is now solved, but if you encounter stunnel failing to start when you next upgrade then this might be a candidate to look at. Ian

1 0

Can't Connect To Gmail
by lrogersjunk＠gmail.com 17 Oct '20

17 Oct '20

Hello all - I have tried to set up stunnel to send emails through gmail from a legacy device that can only send to port 25. But I'm having no success. My config file seems correct, as it matches config files posted by others who appear able to send through gmail. This is what it looks like: output = stunnel-log.txt debug = 7 Taskbar = yes [gmail-imap] client = yes accept = 143 connect = imap.gmail.com:993 verifyChain = yes CAfile = ca-certs.pem checkHost = imap.gmail.com OCSPaia = yes [gmail-smtp] client = yes accept = 25 connect = smtp.gmail.com:465 verifyChain = yes CAfile = ca-certs.pem checkHost = smtp.gmail.com OCSPaia = yes I originally thought the problem was gmail's recent new security features, requiring app-passwords for apps that do not support gmail's latest security features. So I set up an app-password for use by stunnel but that didn't work, either. So I then turned on "allow less secure apps" in gmail and used the account's original password (not the app-password). But even that doesn't work. So I'm at a total loss and can't think of anything else to do. Can anyone assist? Many thanks.

4 3

Stunnel & Gmail security
by BOXI31 TEST 16 Oct '20

16 Oct '20

Hi all, To make "Stunnel 5.31" work with Gmail, I have to go in security settings of Gmail and "allow less secure apps to access my account". Is it mandatory ? Is it possible to set Stunnel to access Gmail without lowering it security level ? How ? I checked in log file TLS v1.2 is used by Stunnel but Gmail still consider it as a "less secure app." ! Regards, Steve

2 1

clarification on Security BugFix released in version 5.57
by svitatissimo2004＠hotmail.com 15 Oct '20

15 Oct '20

looking the changelog of latest version of stunnle (version 5.57) I see the following statement: "The "redirect" option was fixed to properly handle "verifyChain = yes" (thx to Rob Hoes)." It is possible to have more information on the vulnerability fixed?

1 0

clarification on Security BugFix released in version 5.57
by svitatissimo2004＠hotmail.com 15 Oct '20

15 Oct '20

looking the changelog of latest version of stunnle (version 5.57) I see the following statement: "The "redirect" option was fixed to properly handle "verifyChain = yes" (thx to Rob Hoes)." It is possible to have more information on the vulnerability fixed?

1 0

CERT: Pre-verification error: unsupported certificate purpose
by Bob Bob 12 Oct '20

12 Oct '20

Hi, I just updated to version 5.57 and the config I used for ever does not work anymore. I regenerated the self certs using the "Build a Self-signed stunnel.pem" in Windows and made sure the CN was matching the hostname of the server machine. I understand there is an issue with the self signed certificate... ...but it was working fine under 5.56. Server configuration [Server_SyncThing] cert = stunnel.pem accept = 999 connect = 127.0.0.1:24596 ciphers = PSK PSKsecrets = psk.txt Client configuration [SyncThing] client = yes accept = 127.0.0.1:24596 connect = 192.168.0.102:999 verifyPeer = yes CAfile = stunnel.pem PSKsecrets = psk.txt Service [SyncThing] connected remote server from 192.168.1.44:5455 2020.10.12 14:25:06 LOG7[33]: Setting remote socket options (FD=1516) 2020.10.12 14:25:06 LOG7[33]: Option TCP_NODELAY set on remote socket 2020.10.12 14:25:06 LOG7[33]: Remote descriptor (FD=1516) initialized 2020.10.12 14:25:06 LOG6[33]: SNI: sending servername: 192.168.0.102 2020.10.12 14:25:06 LOG6[33]: Peer certificate required 2020.10.12 14:25:06 LOG7[33]: TLS state (connect): before SSL initialization 2020.10.12 14:25:06 LOG7[33]: Initializing application specific data for session authenticated 2020.10.12 14:25:06 LOG6[33]: PSK client configured for identity "user1" 2020.10.12 14:25:06 LOG7[33]: Initializing application specific data for session authenticated 2020.10.12 14:25:06 LOG7[33]: TLS state (connect): SSLv3/TLS write client hello 2020.10.12 14:25:06 LOG7[33]: TLS state (connect): SSLv3/TLS write client hello 2020.10.12 14:25:06 LOG7[33]: TLS state (connect): SSLv3/TLS read server hello 2020.10.12 14:25:06 LOG7[33]: TLS state (connect): TLSv1.3 read encrypted extensions 2020.10.12 14:25:06 LOG7[33]: Verification started at depth=0: C=FR, ST=Centre, L=Marseilles, O=CA, OU=CA, CN= TRUCK-D98J8TY 2020.10.12 14:25:06 LOG4[33]: CERT: Pre-verification error: unsupported certificate purpose 2020.10.12 14:25:06 LOG4[33]: Rejected by CERT at depth=0: C=FR, ST=Centre, L=Marseilles, O=CA, OU=CA, CN= TRUCK-D98J8TY 2020.10.12 14:25:06 LOG7[33]: TLS alert (write): fatal: unsupported certificate 2020.10.12 14:25:06 LOG3[33]: SSL_connect: ssl/statem/statem_clnt.c:1913: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed 2020.10.12 14:25:06 LOG5[33]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket 2020.10.12 14:25:06 LOG7[33]: Deallocating application specific data for session connect address 2020.10.12 14:25:06 LOG7[33]: Deallocating application specific data for session connect address 2020.10.12 14:25:06 LOG7[33]: Remote descriptor (FD=1516) closed Any help would be welcome. Thanks.

2 1