- stunnel-users - stunnel.org

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

Stunnel version 5.63 and openssl 3.0.2 CA signature digest algorithm too weak
by c t browne 30 Mar '22

30 Mar '22

I upgraded to version 5.63 on openssl 3.02 and received a CA signature digest algorithm too week error. I tried setting the securityLevel to 2 and also to 1 and the error did not go away. I have no way to change the certificate on the remove system. Is there an way around this problem? Thanks, Carter

2 2

Can parent proxy see what's going through stunnel
by mingheng wang 27 Mar '22

27 Mar '22

Hi community, I'm using stunnel behind my company proxy like this: protocol=connect connect=proxy.ourcompany.com:3128 protocolHost=myownproxy.net:443 Since I notice that our company seems to be intercepting HTTPS because my web browser sometimes sees our company's certificate instead of the real websites'. So I want to make sure if the company proxy can see what's going through stunnel. Thanks in advance.

1 0

Stunnel aborted the workflow silently in half way
by ygaochn＠amazon.com 24 Mar '22

24 Mar '22

Hey stunnel-users, We are using stunnel as the encryption transit between our NFS client and server. Recently we detected that the stunnel aborted the workflow silently in half way for unknown reason. We'd like to understand what could be the potential reason that cause the issue. Stunnel version: 4.56/5.56, below logs are for 4.56, 5.56 is from customer report without detail log Occurance #1: 2022.03.17 02:19:58 LOG7[1105:139990955783936]: connect_blocking: s_poll_wait IP:PORT: waiting 10 seconds # -> There should be a `TIMEOUTconnect exceeded` failure if the connection failed, but there is no info about how is the waiting going on, there is no log further 2022.03.17 02:56:09 LOG7[1105:139990955789440]: Dispatching signals from the signal pipe Occurance #2: 2022.03.23 16:10:49 LOG6[19003:140551554406144]: CERT: Host name "**" matched with "**" # Aborted again, this is the handshake phase 2022.03.23 16:56:09 LOG7[19003:140551554411648]: Dispatching signals from the signal pipe From the PCAP of the #2 occurance, there is no client side cert and key send to server side, so we can rule out the network issue. 8510 2022-03-23 16:09:47.660910 A B TLSv1.2 5507 Server Hello, Certificate[Packet size limited during capture] 8511 2022-03-23 16:09:47.660919 B A TCP 68 38390 → 2049 [ACK] Seq=340 Ack=5440 Win=57472 Len=0 TSval=698509941 TSecr=1821371384 ... No other client side packet send to server side afterwards, server side are waiting Does anyone encounter this before? I searched the archive but there is no similar issue. What could cause stunnel swallow all the subsequent workflow? Thanks.

1 0

Fix the expansion of @sysconfdir@ in the sample config file
by Peter Pentchev 19 Mar '22

19 Mar '22

Hi, Thanks a lot for writing and maintaining stunnel over the years! What do you think about the attached trivial patch that makes sure @sysconfdir@ is expanded correctly in the sample config file? If something should go wrong with the attachment, it is also available at: https://salsa.debian.org/debian/stunnel/-/blob/master/debian/patches/05-sam… Thanks in advance, and keep up the great work! G'luck, Peter -- Peter Pentchev roam(a)ringlet.net roam(a)debian.org pp(a)storpool.com PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13

1 0

the stunnel stops showing the ssl after a few hours of operation
by Daniel Cordero Gonzalez 18 Mar '22

18 Mar '22

I send an image of the error presented by the stunnel

1 0

the stunnel stops showing the ssl after a few hours of operation
by daniel＠hostingtico.com 18 Mar '22

18 Mar '22

hello, thank you very much for the opportunity to humbly ask for help, I had a server with centos 6 for approximately 3 years and the stunnel never gave me any problem, I recently changed my server with centos 7 but now after a few hours of being active it stops showing the ssl in the ports that I have configured to show shoutcast when viewing the stunnel status: service stunnel status after a few hours it shows most of the result in red and there it does not show the shoutcast in ssl, after giving restart: service stunnel restart everything returns to normal but before 6 hours the problem returns, Could someone give me a light to solve this problem, I'm running the latest version of stunnel my stunnel.conf: client=no [Orto] accept=7000 connect=208.77.20.179:8006 cert = /etc/stunnel/stunnel.pem sslVersion = TLSv1.2 [radio] accept=7002 connect=208.77.20.179:9942 cert = /etc/stunnel/stunnel.pem sslVersion = TLSv1.2 [Metro] accept=7004 connect=208.77.20.179:8014 cert = /etc/stunnel/stunnel.pem sslVersion = TLSv1.2 [arrge] accept=7006 connect=208.77.20.179:8016 cert = /etc/stunnel/stunnel.pem sslVersion = TLSv1.2 [radio2] accept=7008 connect=208.77.20.179:9932 cert = /etc/stunnel/stunnel.pem sslVersion = TLSv1.2 [Radiored] accept=7010 connect=208.77.20.179:8023 cert = /etc/stunnel/stunnel.pem sslVersion = TLSv1.2

1 0