- stunnel-users - stunnel.org

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

Stunnel inetd Linux configuration
by Marco Marchi 30 Sep '20

30 Sep '20

Good morning, I'm trying to configure Stunnel on Linux (Slackware 14). Can anybody post an example of configuration file in order to run and manage Stunnel by means of inetd, keeping in mind that goal is to secure pop3 and imap? Openssl is already installed and running (version 1.1.1g, april 2020). Stunnel version downloaded and installed is 5.56. Certifcate has been generated by means of Openssl. Issues are related to the right syntax in stunnel.conf. Thank you in advance. Marco

1 0

sslVersion
by Ray 25 Sep '20

25 Sep '20

Hi Is sslVersion a global parameter that belongs to all segments or can it be inside a segment to only affect that segment? Example: output = /tmp/stunnel.log debug = emerg sslVersion = all # I assume it is applied to all Stunnel connection definitions [Stunnel_1] sslVersion = tls1_2 # How about this? I only want Stunnel_1 to be affected with sslVersion tls1_2 option. client = yes accept = 2222 connect = some_domain.com.au:8449 verify = 2 CAfile = /etc/stunnel/certs/root_digicert_ca.crt Thanks Ray

1 0

Address already in use (98) error trying to run stunnel client in Ubuntu Docker container
by greg＠yesenergy.com 24 Sep '20

24 Sep '20

Hello all, I'm getting the following error when I try to connect to a remote server from inside a running Docker container: "Binding service [client] to 127.0.0.1:1589: Address already in use (98)". I don't think this port is actually in use, and I've tried other ports with the same results. I know that this configuration works in my Windows dev machine, from which I have consistently connected to the remote server, no problem. I suspect this might be related to Docker's internal networking schema and port-forwarding, but I thought I would ask this group if anyone knows how to overcome this hurdle. Thanks for listening! Here is the config: [client] client = yes accept = 127.0.0.1:1589 connect = nn.nnn.nnn.nnn:443 checkHost = xxxxxxxxx.com sslVersion = TLSv1.2 CAfile = /usr/local/etc/stunnel/my_pemfile.pem verifyPeer = yes Here is the log trace: [ ] Clients allowed=512000 [.] stunnel 5.56 on x86_64-pc-linux-gnu platform [.] Compiled/running with OpenSSL 1.1.1d 10 Sep 2019 [.] Threading:PTHREAD Sockets:POLL,IPv6 TLS:ENGINE,FIPS,OCSP,PSK,SNI [ ] errno: (*__errno_location ()) [.] Reading configuration from file /usr/local/etc/stunnel/stunnel.conf [.] UTF-8 byte order mark detected [.] FIPS mode disabled [ ] Compression disabled [ ] No PRNG seeding was required [ ] Initializing service [client] [ ] Ciphers: DES-CBC3-SHA:IDEA-CBC-MD5-DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA [ ] TLSv1.3 ciphersuites: TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256 [ ] TLS options: 0x02100004 (+0x00000000, -0x00000000) [ ] No certificate or private key specified [.] Configuration successful [ ] Binding service [client] [ ] Listening file descriptor created (FD=8) [ ] Setting accept socket options (FD=8) [ ] Option SO_REUSEADDR set on accept socket [.] Binding service [client] to 127.0.0.1:1589: Address already in use (98) [ ] Listening file descriptor created (FD=8) [ ] Setting accept socket options (FD=8) [ ] Option SO_REUSEADDR set on accept socket [.] Binding service [client] to 127.0.0.1:1589: Address already in use (98) [!] Binding service [client] failed [ ] Deallocating section defaults [ ] Unbinding service [client] [ ] Service [client] closed [ ] Deallocating section [client]

1 0