stunnel-users

stunnel-users@stunnel.org

6 participants
3294 discussions

Stunnel - TLS error unexpected eof while reading
by rick.gregson＠gmail.com 19 May '22

19 May '22

Hi All, I have recently configured stunnel on a Windows Server, it has been configured using a certificate from our internal CA and appears to be functioning ok. However we have a load balancer that is doing a health check against the service and is polling S-Tunnel availability every 5 seconds each time a poll occurs I am seeing the error posted below in the logs. 2022.05.12 10:22:55 LOG3[4113]: SSL_read: ssl/record/rec_layer_s3.c:308: error:0A000126:SSL routines::unexpected eof while reading 2022.05.12 10:22:55 LOG5[4113]: Connection reset: 217 byte(s) sent to TLS, 49 byte(s) sent to socket Can I please have some advice on how to stop this error? Thank you Rick

2 3

Getting error "CERT: Pre-verification error: self signed certificate"
by Christopher Schultz 14 May '22

14 May '22

All, I'm running stunnel 4.56 as a server on Linux, as I have been doing for a while. I require clients to connect using their own client certs and yesterday one of them expired. The client generated a new certificate and sent it to me to install, and I'm getting the error in the subject. Version details: $ sudo stunnel -help stunnel 4.56 on x86_64-koji-linux-gnu platform Compiled/running with OpenSSL 1.0.2k-fips 26 Jan 2017 Threading:PTHREAD Sockets:POLL,IPv6 SSL:ENGINE,OCSP,FIPS Auth:LIBWRAP I have set verify=4 because I expect to place the exact certificate for every client into my CAFile. This has been working for years, and when I connect using openssl s_client, I can see which client certificates the server advertises it will allow to connect, and they reflect what I expect. The server certificate is also self-signed, so I copied that into the CAFile and I'm able to connect with openssl s_client using that certificate. So I think the problem can't be that the client's certificate is self-signed. So, to recap: 1. stunnel in server mode 2. CAFile points to a collection of PEM certs 3. verify=4 4. I can connect with my own valid, trusted, self-signed certificate 5. Client cannot connect with their valid, trusted, self-signed cert Any ideas? (Note: the client DOES appear to be using their new certificate, though I can only see the subject text which could be the same, yet with a different actual certificate.) Here is the debug(7) output from an attempted connection: : Starting certificate verification: depth=0, [subject] : CERT: Pre-verification error: self signed certificate : Certificate check failed: depth=0, [subject] : SSL alert (write): fatal: unknown CA : SSL_accept: 14089086: error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed : Connection reset: 0 byte(s) sent to SSL, 0 byte(s) sent to socket Thanks, -chris

1 1

Is stunnel really compliant with RFC 2487 / RFC 3207 ?
by Javier 13 May '22

13 May '22

Hi, first of all, I still use a 32-bit release (the latest, I think), so maybe things have changed on Stunnel since. But the statement that the protocol smtp option for a service is compliant with RFC 2487, should be 3207 (it is from 2002!), has been in the docs for ages, even in the latest version, 5.64: *** smtp Based on RFC 2487 - SMTP Service Extension for Secure SMTP over TLS *** Long ago I tested the protocol=smtp options as both, clients and server service, and I noticed that, and I think I told here to the list confirming it (maybe for some user using it on client mode), the option implied STARTTLS. Back then I didn't pay much attention to it. BUT the other day I was re-testing for a server service (own mail server sometimes I run) and... I said to my self that this shouldn't be like it was and well, I read the RFC and what tells is the following: *** A publicly-referenced SMTP server MUST NOT require use of the STARTTLS extension in order to deliver mail locally. This rule prevents the STARTTLS extension from damaging the interoperability of the Internet's SMTP infrastructure. A publicly-referenced SMTP server is an SMTP server which runs on port 25 of an Internet host listed in the MX record (or A record if an MX record is not present) for the domain name on the right hand side of an Internet mail address. *** https://datatracker.ietf.org/doc/html/rfc3207#section-4 So, if we use Stunnel to provide THE OPTION of secure TLS connections to other MTAs (MTA to MTA, or server to server) we are against the RFC itself as every connection to port 25 must be encrypted, or nothing, because, as Stunnel is the door to the port and only accepts the STARTTLS command, without redirecting any data to the mail server, no traffic on plain text reaches the server. Acting as a MSA (users - servers) there is no problem because, even if it hadn't/hasn't been widely supported, there are two ports 587 for plain text and 465 for TLS. So Stunnel could be set up to listen on 465 port only, directly accepting TLS sessions or after STARTTLS command (rejecting, in this case, those that don't want a secure channel). We have told several times, specially to newcomers (asking for http proxy, basically), that Stunnel isn't proxy, and it isn't, but in the case of a mail server it should act as is if we use it for a MTA mail server. It acts as is sending the welcome message from the mail server to the other MTA, but once the other MTA doesn't send a STARTTLS command, it closes the connection when, actually, what should do is pass all the dialog between MTAs. I think that is what Stunnel should do. And when just passing messages from mail server to the other MTA, just disable the logging for that connection. After all, the mail severs have already their own logs and there is no reason to log it on Stunnel, nor on the log screen/Stunnel window. Maybe just a line like "redirecting connection to the mail server". Said all the above, do latest versions behave differently? Do you think is a change that should be made to Stunnel to comply with the RFC, if on latest versions don't do yet, or am I wrong somewhere in my statement? Regards. P.S.: MTA: Mail Transfer Agent MSA: Mail Submission Agent MUA: Mail User Agent

3 5

GMail and OAuth 2.0
by Colin Knight 12 May '22

12 May '22

I’ve received an email from Google advising that it will no longer be able to login to Gmail with older third party apps using just username/password. Minimum login security requirements for software are now OAuth 2.0 or similar. I’m using an iPhone to post this which won’t be affected but my laptop uses POP3 collection via Foxmail and Stunnel. I must have continued access to mail on my laptop so will I have to dump Gmail or does Stunnel use OAuth 2.0 (it’s not in my config file.) Advice appreciated.

2 1

stunnel 5.64 released
by Michał Trojnara 06 May '22

06 May '22

Dear Users, I have released version 5.64 of stunnel. This release only includes Windows fixes and improvements. ### Version 5.64, 2022.05.06, urgency: MEDIUM * Security bugfixes - OpenSSL DLLs updated to version 3.0.3. * New features - Updated the pkcs11 engine for Windows. * Bugfixes - Removed the SERVICE_INTERACTIVE_PROCESS flag in "stunnel -install". Home page: https://www.stunnel.org/ Download: https://www.stunnel.org/downloads.html SHA-256 hashes: eebe53ed116ba43b2e786762b0c2b91511e7b74857ad4765824e7199e6faf883 stunnel-5.64.tar.gz 600e76b52a86b21f97a1af13734fdd2226c26646bb77f5f9f074ba3d5755f024 stunnel-5.64-win64-installer.exe 391db6166b22a6648fd1f1df584c13ade61c93f620e46b12ebb30b643e61d2d3 stunnel-5.64-android.zip Best regards, Mike

1 0

Handling AUTH LOGIN for SMTP
by reaperunknown＠live.com 22 Apr '22

22 Apr '22

Hello everyone. Perhaps I'm a little new with Stunnel but, I've successfully used it to get an old EarthLink MailStation compatible with GMail SMTP and POP mail. Kind of neat. That said, I wish to use Outlook, but going through the SMTP process manually via Telnet, I've found that the SMTP requires you issue "AUTH LOGIN" command, and give the username and password in Base64. If I do this manually, I can send SMTP mail all day. However, this unit is old enough that I don't think it knows how to do anything with SMTP auth. It also looks like Outlook doesn't turn SMTP auth off for Outlook.com personal accounts. Is there any way that I've missed to have Stunnel handle the AUTH LOGIN part of the SMTP process, so that device that can't, doesn't have to? Thanks!

2 1

Force PSK Authentication
by gerhard＠ats.hacktic.nl 19 Apr '22

19 Apr '22

Hi stunnel-users, Is there a way to force PSK Authentication? Current behavior is that if the client has no PSK Authentication configured, no authentication is performed and the connection proceeds even when the server has this configured: ciphers = PSK PSKsecrets = mypsk.txt Is this expected behavior? Is there a way to enforce PSK, in other words block clients without PSK Authentication? Thanks

2 1

Windows service won't start. ""The Stunnel TLS wrapper service is marked as an interactive service."
by robert.croteau＠quest.com 15 Apr '22

15 Apr '22

Window 10 LTCS (1089): "The Stunnel TLS wrapper service is marked as an interactive service. However, the system is configured to not allow interactive services. This service may not function properly." looks like starting with version 5.61, this above error appears in the System Event log. I've given a quick glance at the changes from 5.60 to 5.61 and there a lot of them. From the release notes, seems that windows services code might have been affected: New features for the Windows platform - Added client mode allowing authenticated users to view logs, reconfigure and terminate running stunnel services. - Added support for multiple GUI and service instances distinguised by the location of stunnel.conf. On GitHub, I also noticed that in the source code for src/ui_win_gui.c the service is created as follows: service=CreateService(scm, SERVICE_NAME, SERVICE_DISPLAY_NAME, SERVICE_ALL_ACCESS, SERVICE_WIN32_OWN_PROCESS|SERVICE_INTERACTIVE_PROCESS, SERVICE_AUTO_START, SERVICE_ERROR_NORMAL, service_path, NULL, NULL, TEXT("TCPIP\0"), NULL, NULL);ui_win_gui.c at around line 1622 the SERVICE_INTERACTIVE_PROCESS flag is set Is this flag necessary? I guess that would be the culprit. my reason to upgrade is because of the CVE-2022-0778 OpenSSL vulnerability anyone has a workaround for this? Microsoft has fully disabled Interactive Service Detection starting with Windows 10 Build 1803 and Windows Server 2016 and 2019. So, it looks like that that Interactive services are no longer allowed and this can't be circumvented by changing some registry setting like it seems it was possible before. thank you

3 5

issue with vendor trying to use proxy for tls
by Daniel Trickett 14 Apr '22

14 Apr '22

Hi stunnelers, We have a supplier which we are attempting punchout to ecommerce site. We use the url http://local-val.dc-clic.com:8899/punchout/request/0fd1ef2b-d09a-441d-b161-… to initiate punchout. The host local-val.dc.clic.com routes to our local host, where stunnel is listening on port 8899. Our config file contains the following below. accept = local-val.dc-clic.com:8899 connect = val.dc-clic.com:443 The application fails to connect and is trying to connect using the incorrect url. Error Code: 202 Supplier Site Does Not Respond Unable to send the Login Request XML. Supplier Login URL: http://local-val.dc-clic.com:8899/punchout/request/0fd1ef2b-d09a-441d-b161-… We use stunnel as tls proxy for various suppliers and have been encountering more issues lately. I am feeling that the long string after the request is causing an issue for stunnel, but unclear to us. Our understanding is stunnel will open the connection to https:// val.dc-clic.com:443/punchout/request/0fd1ef2b-d09a-441d-b161-5ada0e226b80. Stunnel log indicates that a connection is opened to val.dc-clic.com. Any help appreciated! Thanks and best regards Dan This message and any attachment are confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you must not copy this message or attachment or disclose the contents to any other person. If you have received this transmission in error, please notify the sender immediately and delete the message and any attachment from your system. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not accept liability for any omissions or errors in this message which may arise as a result of E-Mail-transmission or for damages resulting from any unauthorized changes of the content of this message and any attachment thereto. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not guarantee that this message is free of viruses and does not accept liability for any damages caused by any virus transmitted therewith. Click emdgroup.com/disclaimer<https://www.emdgroup.com/en/legal-disclaimer/mail-disclaimer.html> to access the German, French, Spanish, Portuguese, Turkish, Polish and Slovak versions of this disclaimer. Please find our Privacy Statement information by clicking here: merckgroup.com/privacy-statement-countries<https://www.merckgroup.com/en/privacy-statement/privacy-statement-countries…>

1 0

stunnel log message
by Daniel Trickett 01 Apr '22

01 Apr '22

Hello all, Happy Friday! Hope I can get some clarification on this entry from the stunnel log. The below shows up in our log, our input to stunnel is SSLv3. Is that all this is referring to? TLS state (connect): SSLv3 Thanks for your reply! Best regards, Dan This message and any attachment are confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you must not copy this message or attachment or disclose the contents to any other person. If you have received this transmission in error, please notify the sender immediately and delete the message and any attachment from your system. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not accept liability for any omissions or errors in this message which may arise as a result of E-Mail-transmission or for damages resulting from any unauthorized changes of the content of this message and any attachment thereto. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not guarantee that this message is free of viruses and does not accept liability for any damages caused by any virus transmitted therewith. Click emdgroup.com/disclaimer<https://www.emdgroup.com/en/legal-disclaimer/mail-disclaimer.html> to access the German, French, Spanish, Portuguese, Turkish, Polish and Slovak versions of this disclaimer. Please find our Privacy Statement information by clicking here: merckgroup.com/privacy-statement-countries<https://www.merckgroup.com/en/privacy-statement/privacy-statement-countries…>

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

stunnel-users