- stunnel-users - stunnel.org

Failed to initialize TLS
by Campbell, David 20 Nov '20

20 Nov '20

TLS is not initializing. This is the output. Is there something that I should be including in my conf that would produce this? Or is it just a generic error? [ ] Initializing inetd mode configuration [ ] Running on Windows 6.2 [ ] No limit detected for the number of clients [ ] stunnel 5.57 on x64-pc-mingw32-gnu platform [ ] Compiled/running with OpenSSL 1.1.1h 22 Sep 2020 [ ] Threading WIN32 Sockets:SELECT,IPv6 TLS:ENGINE,OCSP,PSK,SNI [ ] errno: (*_errno()) [ ] GUI message loop initialized [ ] Initializing inetd mode configuration [ ] Running on Windows 6.2 [ . ] Reading configuration from file stunnel.conf [ . ] UTF-8 byte order mark not detected [ ! ] No compression method is available [ ! ] Global options: Failed to initialize TLS [ ! ] Configuration failed [ ] Deallocating temporary section defaults [ ! ] Server is down ________________________________ CONFIDENTIALITY NOTICE: This email constitutes an electronic communication within the meaning of the Electronic Communications Privacy Act, 18 U.S.C. 2510, and its disclosure is strictly limited to the named recipient(s) intended by the sender of this message. This email, and any attachments, may contain confidential and/or proprietary information of Scientific Research Corporation. If you are not a named recipient, any copying, using, disclosing or distributing to others the information in this email and attachments is STRICTLY PROHIBITED. If you have received this email in error, please notify the sender immediately and permanently delete the email, any attachments, and all copies thereof from any drives or storage media and destroy any printouts or hard copies of the email and attachments. EXPORT COMPLIANCE NOTICE: This email and any attachments may contain technical data subject to U.S export restrictions under the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Export or transfer of this technical data and/or related information to any foreign person(s) or entity(ies), either within the U.S. or outside of the U.S., may require advance export authorization by the appropriate U.S. Government agency prior to export or transfer. In addition, technical data may not be exported or transferred to certain countries or specified designated nationals identified by U.S. embargo controls without prior export authorization. By accepting this email and any attachments, all recipients confirm that they understand and will comply with all applicable ITAR, EAR and embargo compliance requirements.

1 0

PSK Configuration
by Giulio Regazzo 16 Nov '20

16 Nov '20

Hi, I'm new to stunnel. And I'm trying to configure a server that accepts TCP sockets connections only from clients that have a pre-shared certificate. Looking at the online documentation I found the verifyPeer option, but it is described to be used on client side. Trying to use it on server side I achieved my goal but only if the client has the whole certificate (private + public). My question is: Can I obtain in some way the same result sharing only the public part of the certificate? Currently I'm using a configuration like this one (skipping the accept and connect options): [Server] cert=wholeCert.pem verifyPeer=yes [Client] cert=wholeCert.pem verifyPeer=yes CAFile=wholeCert.pem and I'm looking for something like: [Server] cert=wholeCert.pem verifyPeer=yes [Client] verifyPeer=yes CAFile=publicCert.pem If I try this second option the server refuses the connection in handshake phase saying that the client didn't provide any certificate. Is there a way to achieve this? Thank you.

2 3

hi
by fieldengineer59＠yahoo.com 04 Nov '20

04 Nov '20

hi

1 0

hi
by fieldengineer59＠yahoo.com 04 Nov '20

04 Nov '20

hi

1 0

hi
by fieldengineer59＠yahoo.com 04 Nov '20

04 Nov '20

hi

1 0

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