stunnel-users

stunnel-users@stunnel.org

6 participants
3294 discussions

stunnel ignoring config file for port binding
by Tim Turner 18 Apr '20

18 Apr '20

Config and logs below but redacted, this is running on 2016 server, if it matters I am starting it over an RDP session I find that the port is ignored in the config file and it always binds to ports in the 23*** range ; Sample stunnel configuration file by Michal Trojnara 2002-2006 ; Some options used here may not be adequate for your particular configuration ; Certificate/key is needed in server mode and optional in client mode ; The default certificate is provided only for testing and should not ; be used in a production environment ;cert = stunnel.pem ;key = stunnel.pem ; Some performance tunings socket = l:TCP_NODELAY=1 socket = r:TCP_NODELAY=1 ; Workaround for Eudora bug ;options = DONT_INSERT_EMPTY_FRAGMENTS ; Authentication stuff ;verify = 2 ; Don't forget to c_rehash CApath ;CApath = certs ; It's often easier to use CAfile ;CAfile = certs.pem ; Don't forget to c_rehash CRLpath ;CRLpath = crls ; Alternatively you can use CRLfile ;CRLfile = crls.pem ; Some debugging stuff useful for troubleshooting debug = 7 output = /stunnel.log ; Use it for client mode client = yes ; Service-level configuration [Service Config] accept=127.0.0.1:40001 connect = redacted:443 log file 2020.04.18 10:08:18 LOG7[main]: Dispatching a signal from the signal pipe 2020.04.18 10:08:18 LOG7[main]: Processing SIGNAL_RELOAD_CONFIG 2020.04.18 10:08:18 LOG7[main]: Running on Windows 6.2 2020.04.18 10:08:18 LOG5[main]: Reading configuration from file stunnel.conf 2020.04.18 10:08:18 LOG5[main]: UTF-8 byte order mark detected 2020.04.18 10:08:18 LOG7[main]: Compression disabled 2020.04.18 10:08:18 LOG7[main]: No PRNG seeding was required 2020.04.18 10:08:18 LOG6[main]: Initializing service [Service Config] 2020.04.18 10:08:18 LOG7[main]: Ciphers: HIGH:!aNULL:!SSLv2:!DH:!kDHEPSK 2020.04.18 10:08:18 LOG7[main]: TLSv1.3 ciphersuites: TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256 2020.04.18 10:08:18 LOG7[main]: TLS options: 0x02100004 (+0x00000000, -0x00000000) 2020.04.18 10:08:18 LOG7[main]: No certificate or private key specified 2020.04.18 10:08:18 LOG4[main]: Service [Digital-Prod-MTF-FIX-MD] needs authentication to prevent MITM attacks 2020.04.18 10:08:18 LOG5[main]: Configuration successful 2020.04.18 10:08:18 LOG7[main]: Deallocating section defaults 2020.04.18 10:08:18 LOG5[main]: Logging to C:\Users\turnert\AppData\Local\/stunnel.log 2020.04.18 10:08:18 LOG7[main]: Binding service [New Broker FIX Demo-Trading] 2020.04.18 10:08:18 LOG7[main]: Listening file descriptor created (FD=1296) 2020.04.18 10:08:18 LOG7[main]: Setting accept socket options (FD=1296) 2020.04.18 10:08:18 LOG7[main]: Option SO_EXCLUSIVEADDRUSE set on accept socket 2020.04.18 10:08:18 LOG6[main]: Service [New Broker FIX Demo-Trading] (FD=1296) bound to 127.0.0.1:23471 2020.04.18 10:08:18 LOG7[main]: Binding service [Service Config] This message and its attachments are confidential, may not be disclosed or used by any person other than the addressee and are intended only for the named recipient(s). If you are not the intended recipient, please notify the sender immediately and delete any copies of this message. LMAX Group is the holding company of LMAX Exchange, LMAX Global and LMAX Digital. Our registered address is Yellow Building, 1A Nicholas Road, London W11 4AN.

1 0

Re: [stunnel-users] stunnel-users Digest, Vol 189, Issue 3
by Brent Kimberley 10 Apr '20

10 Apr '20

Hi Andre. Can you please post your template? Salut, Brent Friday, April 10, 2020, 6:00:08 a.m. EDT, stunnel-users-request(a)stunnel.org <stunnel-users-request(a)stunnel.org> wrote: Send stunnel-users mailing list submissions to stunnel-users(a)stunnel.org To subscribe or unsubscribe via the World Wide Web, visit https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users or, via email, send a message with subject or body 'help' to stunnel-users-request(a)stunnel.org You can reach the person managing the list at stunnel-users-owner(a)stunnel.org When replying, please edit your Subject line so it is more specific than "Re: Contents of stunnel-users digest..." Today's Topics: 1. CERT: Pre-verification error: unsupported certificate purpose (Andr? L?onard) ---------------------------------------------------------------------- Message: 1 Date: Fri, 10 Apr 2020 09:46:29 +0200 From: Andr? L?onard <andre.leonard(a)celotoise.com> To: stunnel-users(a)stunnel.org Subject: [stunnel-users] CERT: Pre-verification error: unsupported certificate purpose Message-ID: <1a2bba7f82b899d6e208303bc3a8ad6d(a)celotoise.com> Content-Type: text/plain; charset="utf-8"; Format="flowed" Hi, I upgraded stunnel from version 5.44 to 5.56. But now I'm getting the following error : CERT: Pre-verification error: unsupported certificate purpose Rejected by CERT Setting verifiy to 0 slove temporary the issue but is not secure at all. As testing pupose, I recreated new certificate with the following command but ending with the same issue: openssl req -new -x509 -days 365 -nodes -config stunnel.cnf -out stunnel.pem -keyout stunnel.pem How to fix this ? Thanks for you help, Andr?.

1 0

CERT: Pre-verification error: unsupported certificate purpose
by André Léonard 10 Apr '20

10 Apr '20

Hi, I upgraded stunnel from version 5.44 to 5.56. But now I'm getting the following error : CERT: Pre-verification error: unsupported certificate purpose Rejected by CERT Setting verifiy to 0 slove temporary the issue but is not secure at all. As testing pupose, I recreated new certificate with the following command but ending with the same issue: openssl req -new -x509 -days 365 -nodes -config stunnel.cnf -out stunnel.pem -keyout stunnel.pem How to fix this ? Thanks for you help, André.

1 0

Stunnel to accept SSL and connect SSL
by Ray 08 Apr '20

08 Apr '20

Hi everyone, Simple question - How can I configure Stunnel to accept SSL from downlinks and connect to an SSL uplink? Thanks Ray

1 0

Stunnel API hooks
by Ray 31 Mar '20

31 Mar '20

Hi everyone, I want to do some processing over the incoming connection before forwarding the payload to the uplinks. ie. Listen <-> customized processing <-> connect Is there any API/hook structure to write my logic in a clean fashion? Or need to add/integrate my codes to the Stunnel codes? P.S I want this processing to be done in Stunnel and not by adding a 2nd application to achieve the job. Thanks Ray

1 0

Stunnel binary for macOS?
by Shrinidhi Rao 22 Mar '20

22 Mar '20

Greetings! I tried building stunnel in my mac and it was successful since I have all the developer tools installed. What about for those who do not have an 8GB size tool? Is there a way I can simply build a binary that can work in a wide range of macOS versions (including older ones)? Is there someone who has already done this? Any pointers in this regard would be greatly appreciated! -- Shrinidhi S Rao

2 1

stunnel squid proxy without client side stunnel
by claudiu vasadi 13 Mar '20

13 Mar '20

Hello list, I've successfully managed to setup the following: client -> stunnel (local on client) -> stunnel (on server) -> squid (same server) I was wondering however if it would be possible to NOT use stunnel on the client side and connect directly to the server side one. My current, working configs are below. simplified server side stunnel.conf: cert = /etc/stunnel/stunnel.pem debug = 7 output = /var/log/stunnel.log client = no [squid] accept = 3128 connect = 127.0.0.1:3129 client side config: cert = /etc/stunnel/stunnel.pem client = yes [squid] accept = 127.0.0.1:8080 connect = server:3128 On the server side, I've tried specifying: client = yes protocol = connect protocolHost = 127.0.0.1:3129 #SSL terminates on the stunnel server (still unsure about this) but because the proxy needs authentication (it used LDAP), I'm hitting what seems to be stunnel not returning the HTTP407 back to the client. 2020.03.13 20:18:34 LOG6[12306:140677061584640]: Client-mode connect protocol negotiations started 2020.03.13 20:18:34 LOG7[12306:140677061584640]: -> CONNECT 127.0.0.1:3129 HTTP/1.1 2020.03.13 20:18:34 LOG7[12306:140677061584640]: -> Host: 127.0.0.1:3129 2020.03.13 20:18:34 LOG7[12306:140677061584640]: -> 2020.03.13 20:18:34 LOG7[12306:140677061584640]: <- HTTP/1.1 407 Proxy Authentication Required 2020.03.13 20:18:34 LOG3[12306:140677061584640]: CONNECT request rejected 2020.03.13 20:18:34 LOG7[12306:140677061584640]: <- Server: squid/3.5.20 2020.03.13 20:18:34 LOG7[12306:140677061584640]: <- Mime-Version: 1.0 2020.03.13 20:18:34 LOG7[12306:140677061584640]: <- Date: Fri, 13 Mar 2020 20:18:34 GMT 2020.03.13 20:18:34 LOG7[12306:140677061584640]: <- Content-Type: text/html;charset=utf-8 2020.03.13 20:18:34 LOG7[12306:140677061584640]: <- Content-Length: 3431 2020.03.13 20:18:34 LOG7[12306:140677061584640]: <- X-Squid-Error: ERR_CACHE_ACCESS_DENIED 0 2020.03.13 20:18:34 LOG7[12306:140677061584640]: <- Vary: Accept-Language 2020.03.13 20:18:34 LOG7[12306:140677061584640]: <- Content-Language: en 2020.03.13 20:18:34 LOG7[12306:140677061584640]: <- Proxy-Authenticate: Basic realm="myproxy" 2020.03.13 20:18:34 LOG7[12306:140677061584640]: <- X-Cache: MISS from myproxy 2020.03.13 20:18:34 LOG7[12306:140677061584640]: <- X-Cache-Lookup: NONE from myproxy:3129 2020.03.13 20:18:34 LOG7[12306:140677061584640]: <- Via: 1.1 myproxy (squid/3.5.20) 2020.03.13 20:18:34 LOG7[12306:140677061584640]: <- Connection: keep-alive 2020.03.13 20:18:34 LOG7[12306:140677061584640]: <- 2020.03.13 20:18:34 LOG5[12306:140677061584640]: Connection reset: 0 byte(s) sent to SSL, 0 byte(s) sent to socket I'm testing with the following command from the client side: curl -U mysuer -x http://myproxy:3128 https://www.google.com Any help would be greatly appreciated.

1 0

S-tunnel will not send TLS
by Jan Falk 13 Mar '20

13 Mar '20

Hi. Can someone tell me why Stunnel stops at wating 10s? Log: 2020.03.12 09:43:36 LOG6[main]: Initializing service [x3_x4_DICOM_BFT_client] 2020.03.12 09:43:36 LOG7[main]: Ciphers: HIGH:!aNULL:!SSLv2:!DH:!kDHEPSK 2020.03.12 09:43:36 LOG7[main]: TLSv1.3 ciphersuites: TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256 2020.03.12 09:43:36 LOG7[main]: TLS options: 0x02100004 (+0x00000000, -0x00000000) 2020.03.12 09:43:36 LOG6[main]: Loading certificate from file: x1.dc.x2.se_201900604.pem 2020.03.12 09:43:36 LOG6[main]: Certificate loaded from file: x1.dc.x2.se_201900604.pem 2020.03.12 09:43:36 LOG6[main]: Loading private key from file: x1.dc.x2.se_201900604.pem 2020.03.12 09:43:36 LOG6[main]: Private key loaded from file: x1.dc.x2.se_201900604.pem 2020.03.12 09:43:36 LOG7[main]: Private key check succeeded 2020.03.12 09:43:36 LOG4[main]: Service [x3_x4_DICOM_BFT_client] uses "verifyChain" without subject checks 2020.03.12 09:43:36 LOG4[main]: Use "checkHost" or "checkIP" to restrict trusted certificates 2020.03.12 09:43:36 LOG5[main]: Configuration successful 2020.03.12 09:43:36 LOG7[main]: Binding service [x3_x4_HL7_BFT_client] 2020.03.12 09:43:36 LOG7[main]: Listening file descriptor created (FD=380) 2020.03.12 09:43:36 LOG7[main]: Setting accept socket options (FD=380) 2020.03.12 09:43:36 LOG7[main]: Option SO_EXCLUSIVEADDRUSE set on accept socket 2020.03.12 09:43:36 LOG6[main]: Service [x3_x4_HL7_BFT_client] (FD=380) bound to 127.0.0.1:46161 2020.03.12 09:43:36 LOG7[main]: Binding service [x3_x4_DICOM_BFT_client] 2020.03.12 09:43:36 LOG7[main]: Listening file descriptor created (FD=492) 2020.03.12 09:43:36 LOG7[main]: Setting accept socket options (FD=492) 2020.03.12 09:43:36 LOG7[main]: Option SO_EXCLUSIVEADDRUSE set on accept socket 2020.03.12 09:43:36 LOG6[main]: Service [x3_x4_DICOM_BFT_client] (FD=492) bound to 127.0.0.1:46162 2020.03.12 09:43:36 LOG7[cron]: Cron thread initialized 2020.03.12 09:43:36 LOG6[cron]: Executing cron jobs 2020.03.12 09:43:36 LOG6[cron]: Cron jobs completed in 0 seconds 2020.03.12 09:43:36 LOG7[cron]: Waiting 86400 seconds 2020.03.12 09:44:37 LOG7[main]: Found 1 ready file descriptor(s) 2020.03.12 09:44:37 LOG7[main]: FD=380 ifds=r-x ofds=r-- 2020.03.12 09:44:37 LOG7[main]: FD=388 ifds=r-x ofds=--- 2020.03.12 09:44:37 LOG7[main]: Service [SOS_SYNGO_HL7_BFT_client] accepted (FD=508) from 127.0.0.1:50299 2020.03.12 09:44:37 LOG7[main]: Creating a new thread 2020.03.12 09:44:37 LOG7[main]: New thread created 2020.03.12 09:44:37 LOG7[0]: Service [x3_x4_HL7_BFT_client] started 2020.03.12 09:44:37 LOG7[0]: Setting local socket options (FD=508) 2020.03.12 09:44:37 LOG7[0]: Option TCP_NODELAY set on local socket 2020.03.12 09:44:37 LOG5[0]: Service [x3_x4_HL7_BFT_client] accepted connection from 127.0.0.1:50299 2020.03.12 09:44:37 LOG6[0]: s_connect: connecting 10.67.6.106:6161 2020.03.12 09:44:37 LOG7[0]: s_connect: s_poll_wait 10.67.6.106:6161: waiting 10 seconds Thanks in advance //Janne

2 5

Re: [stunnel-users] stunnel-users Digest, Vol 188, Issue 4
by Brent Kimberley 11 Mar '20

11 Mar '20

Hi Kelly. >>Connect = 127.0.0.1:1194? ?#<- this line won't work; but if I replace with 1.2.3.4:1194 then it will work! Generic: The following layers maybe helpful: Cost / People / Process / Infrastructure / Application / Data / Interface ... Specific: Data layer (metadata &/| configuration): Can you please verify that 127.0.01:1194 is present? e.g. netstat -ano | egrep -e Proto -e Active -e 1194 Message: 1 Date: Tue, 10 Mar 2020 13:25:33 +0800 From: Kelly Trinh <kelly(a)trinhonline.com> To: "stunnel-users" <stunnel-users(a)stunnel.org> Subject: [stunnel-users] behaviour when using 127.0.0.1 in the 'connect' field Message-ID: <170c2e7c29d.e9c53ed9127299.5279211261811289922(a)trinhonline.com> Content-Type: text/plain; charset="utf-8" Hi all - just want to report a problem I solved recently but wanted to get some insights on what was causing the problem. About me - learnt some unix at university (20 years ago) but nothing too serious.? Recently (1 month ago) acquired own domain name and now poking around the cloud computing / VPS thing. Project - hand-rolling my own VPN setup on a Ubuntu 18.04 VPS.? OpenVPN is easy since it is a git-clone thing and then just follow the openvpn-install script.? I wanted to add on the Stunnel wrapper because intended to use the VPN in China and apparently their firewall does deep packet inspection and can recognize (and block) openvpn traffic. Problem - when I set up my stunnel using 127.0.0.1 as the connect destination; it doesn't seem to work (I can see from openvpn window that things seem to pipe through stunnel but then immediately the connection is terminated).? If I replace the 127.0.0.1 with IP of the box I am using (say for example 1.2.3.4); everything works!? The FQDN is ok as well; as long as I don't use 127.0.0.1 Specifically the stunnel.conf: [OpenVPN] Accept = 443? # clients connect through 443 to further avoid potential blocking Connect = 127.0.0.1:1194? ?#<- this line won't work; but if I replace with 1.2.3.4:1194 then it will work! Question - My problem is fixed but I am curious if there is any insights on why this is happening given that 1.2.3.4 and 127.0.0.1 are the same machine?

1 0

behaviour when using 127.0.0.1 in the 'connect' field
by Kelly Trinh 10 Mar '20

10 Mar '20

Hi all - just want to report a problem I solved recently but wanted to get some insights on what was causing the problem. About me - learnt some unix at university (20 years ago) but nothing too serious. Recently (1 month ago) acquired own domain name and now poking around the cloud computing / VPS thing. Project - hand-rolling my own VPN setup on a Ubuntu 18.04 VPS. OpenVPN is easy since it is a git-clone thing and then just follow the openvpn-install script. I wanted to add on the Stunnel wrapper because intended to use the VPN in China and apparently their firewall does deep packet inspection and can recognize (and block) openvpn traffic. Problem - when I set up my stunnel using 127.0.0.1 as the connect destination; it doesn't seem to work (I can see from openvpn window that things seem to pipe through stunnel but then immediately the connection is terminated). If I replace the 127.0.0.1 with IP of the box I am using (say for example 1.2.3.4); everything works! The FQDN is ok as well; as long as I don't use 127.0.0.1 Specifically the stunnel.conf: [OpenVPN] Accept = 443 # clients connect through 443 to further avoid potential blocking Connect = 127.0.0.1:1194 #<- this line won't work; but if I replace with 1.2.3.4:1194 then it will work! Question - My problem is fixed but I am curious if there is any insights on why this is happening given that 1.2.3.4 and 127.0.0.1 are the same machine?

3 3

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