stunnel-users

stunnel-users@stunnel.org

6 participants
3294 discussions

Re: [stunnel-users] [EXTERNAL] Re: Stunnel connection issue?
by Eric S Eberhard 09 Jul '18

09 Jul '18

I should also point out that the cipher suite is related to openssl version stunnel is compiled with. Again, we had customers that connected with TLSv1.3 and then could not negotiate a cipher suite ... leading to lost connection. Make sure you update openssl first -- then compile stunnel. Eric Eric S Eberhard VICS (Vertical Integrated Computer Systems) Voice: 928 567 3529 Cell : 928 301 7537 (not reliable except for text or if not home) 2933 W Middle Verde Rd Camp Verde, AZ 86322 -----Original Message----- From: stunnel-users [mailto:stunnel-users-bounces@stunnel.org] On Behalf Of Javier Sent: Monday, July 09, 2018 9:55 AM To: stunnel-users(a)stunnel.org Subject: Re: [stunnel-users] [EXTERNAL] Re: Stunnel connection issue? On Mon, 9 Jul 2018 12:26:08 +0000 Daniel Trickett <daniel.trickett(a)emdmillipore.com> wrote: > > Will, > > I was told to ignore the SSLv3 stuff in the log. I have options set to > allow only TLS1.2 and still see SSLv3 references in the log. > > Best regards, > > Dan Hi, in fact, the version can be disclosed from following lines in the log, where is told the cipher used, but not where you usually look: LOG6[1]: TLSv(1-1.1-1.2-1.3-whatever) ciphersuite: (whatever) Regards. _______________________________________________ stunnel-users mailing list stunnel-users(a)stunnel.org https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users

1 0

Stunnel connection issue?
by Spies, Will 09 Jul '18

09 Jul '18

I've been trying to get Stunnel to work for some time now. I have avoided using the mail list - but I see no recourse now. I think I've tried just about every setting I could find. I appear to be getting a connection issue - but as you will see the log just doesn't indicate clearly what is going on. The behavior is my client is failing to get a connection through Stunnel to my backend. The log appears to be closing a socket (but can't tell which one frontend or backend). Nothing wrong happens up until a client connects - 443 binds fine and later a connection to my backend 554 appears to connect find. If someone/anyone can help direct me to how to trouble shoot this better I would greatly appreciate it. As you will see in the log - the client attempts twice to get through. An excerpt of my log and the conf is below. /etc/stunnel.conf: socket = l:TCP_NODELAY=1 socket = r:TCP_NODELAY=1 output = /var/log/stunnel.log debug=7 [rtsp] cert = /etc/stunnel/stunnel.pem accept=192.168.112.16:443 connect=192.168.112.16:554 TIMEOUTclose = 0 TIMEOUTbusy = 5 TIMEOUTidle = 30 delay = yes sslVersion = TLSv1.2 /var/log/stunnel.log: 2018.07.05 05:31:01 LOG7[main]: Service [rtsp] accepted (FD=3) from 192.168.112.197:43869 2018.07.05 05:31:01 LOG7[5]: Service [rtsp] started 2018.07.05 05:31:01 LOG7[5]: Setting local socket options (FD=3) 2018.07.05 05:31:01 LOG7[5]: Option TCP_NODELAY set on local socket 2018.07.05 05:31:01 LOG5[5]: Service [rtsp] accepted connection from 192.168.112.197:43869 2018.07.05 05:31:01 LOG6[5]: Peer certificate not required 2018.07.05 05:31:01 LOG7[5]: TLS state (accept): before SSL initialization 2018.07.05 05:31:01 LOG7[5]: TLS state (accept): before SSL initialization 2018.07.05 05:31:01 LOG7[5]: SNI: no virtual services defined 2018.07.05 05:31:01 LOG7[5]: TLS state (accept): SSLv3/TLS read client hello 2018.07.05 05:31:01 LOG7[5]: TLS state (accept): SSLv3/TLS write server hello 2018.07.05 05:31:01 LOG7[5]: TLS state (accept): SSLv3/TLS write certificate 2018.07.05 05:31:01 LOG7[5]: TLS state (accept): SSLv3/TLS write key exchange 2018.07.05 05:31:01 LOG7[5]: TLS state (accept): SSLv3/TLS write server done 2018.07.05 05:31:01 LOG7[5]: TLS state (accept): SSLv3/TLS write server done 2018.07.05 05:31:01 LOG7[5]: TLS state (accept): SSLv3/TLS read client key exchange 2018.07.05 05:31:01 LOG7[5]: TLS state (accept): SSLv3/TLS read change cipher spec 2018.07.05 05:31:01 LOG7[5]: TLS state (accept): SSLv3/TLS read finished 2018.07.05 05:31:01 LOG7[5]: TLS state (accept): SSLv3/TLS write change cipher spec 2018.07.05 05:31:01 LOG7[5]: TLS state (accept): SSLv3/TLS write finished 2018.07.05 05:31:01 LOG7[5]: New session callback 2018.07.05 05:31:01 LOG6[5]: No peer certificate received 2018.07.05 05:31:01 LOG7[5]: 6 server accept(s) requested 2018.07.05 05:31:01 LOG7[5]: 3 server accept(s) succeeded 2018.07.05 05:31:01 LOG7[5]: 0 server renegotiation(s) requested 2018.07.05 05:31:01 LOG7[5]: 0 session reuse(s) 2018.07.05 05:31:01 LOG7[5]: 3 internal session cache item(s) 2018.07.05 05:31:01 LOG7[5]: 0 internal session cache fill-up(s) 2018.07.05 05:31:01 LOG7[5]: 0 internal session cache miss(es) 2018.07.05 05:31:01 LOG7[5]: 0 external session cache hit(s) 2018.07.05 05:31:01 LOG7[5]: 0 expired session(s) retrieved 2018.07.05 05:31:01 LOG6[5]: TLS accepted: new session negotiated 2018.07.05 05:31:01 LOG6[5]: TLSv1.2 ciphersuite: ECDHE-RSA-AES256-GCM-SHA384 (256-bit encryption) 2018.07.05 05:31:01 LOG7[5]: Compression: null, expansion: null 2018.07.05 05:31:01 LOG6[5]: s_connect: connecting 192.168.112.16:554 2018.07.05 05:31:01 LOG7[5]: s_connect: s_poll_wait 192.168.112.16:554: waiting 10 seconds 2018.07.05 05:31:01 LOG5[5]: s_connect: connected 192.168.112.16:554 2018.07.05 05:31:01 LOG6[5]: persistence: 192.168.112.16:554 cached 2018.07.05 05:31:01 LOG5[5]: Service [rtsp] connected remote server from 192.168.112.16:58594 2018.07.05 05:31:01 LOG7[5]: Setting remote socket options (FD=9) 2018.07.05 05:31:01 LOG7[5]: Option TCP_NODELAY set on remote socket 2018.07.05 05:31:01 LOG7[5]: Remote descriptor (FD=9) initialized 2018.07.05 05:31:02 LOG6[5]: TLS socket closed (SSL_read) 2018.07.05 05:31:02 LOG7[5]: Sent socket write shutdown 2018.07.05 05:31:02 LOG5[5]: Connection closed: 0 byte(s) sent to TLS, 0 byte(s) sent to socket 2018.07.05 05:31:02 LOG7[5]: Remote descriptor (FD=9) closed 2018.07.05 05:31:02 LOG7[5]: Local descriptor (FD=3) closed 2018.07.05 05:31:02 LOG7[5]: Service [rtsp] finished (0 left) 2018.07.05 05:31:02 LOG7[main]: Found 1 ready file descriptor(s) 2018.07.05 05:31:02 LOG7[main]: FD=4 events=0x2001 revents=0x0 2018.07.05 05:31:02 LOG7[main]: FD=7 events=0x2001 revents=0x1 2018.07.05 05:31:02 LOG7[main]: Service [rtsp] accepted (FD=3) from 192.168.112.197:43870 2018.07.05 05:31:02 LOG7[6]: Service [rtsp] started 2018.07.05 05:31:02 LOG7[6]: Setting local socket options (FD=3) 2018.07.05 05:31:02 LOG7[6]: Option TCP_NODELAY set on local socket 2018.07.05 05:31:02 LOG5[6]: Service [rtsp] accepted connection from 192.168.112.197:43870 2018.07.05 05:31:02 LOG6[6]: Peer certificate not required 2018.07.05 05:31:02 LOG7[6]: TLS state (accept): before SSL initialization 2018.07.05 05:31:02 LOG7[6]: TLS state (accept): before SSL initialization 2018.07.05 05:31:02 LOG7[6]: SNI: no virtual services defined 2018.07.05 05:31:02 LOG7[6]: TLS state (accept): SSLv3/TLS read client hello 2018.07.05 05:31:02 LOG7[6]: TLS state (accept): SSLv3/TLS write server hello 2018.07.05 05:31:02 LOG7[6]: TLS state (accept): SSLv3/TLS write certificate 2018.07.05 05:31:02 LOG7[6]: TLS state (accept): SSLv3/TLS write key exchange 2018.07.05 05:31:02 LOG7[6]: TLS state (accept): SSLv3/TLS write server done 2018.07.05 05:31:02 LOG7[6]: TLS state (accept): SSLv3/TLS write server done 2018.07.05 05:31:02 LOG7[6]: TLS state (accept): SSLv3/TLS read client key exchange 2018.07.05 05:31:02 LOG7[6]: TLS state (accept): SSLv3/TLS read change cipher spec 2018.07.05 05:31:02 LOG7[6]: TLS state (accept): SSLv3/TLS read finished 2018.07.05 05:31:02 LOG7[6]: TLS state (accept): SSLv3/TLS write change cipher spec 2018.07.05 05:31:02 LOG7[6]: TLS state (accept): SSLv3/TLS write finished 2018.07.05 05:31:02 LOG7[6]: New session callback 2018.07.05 05:31:02 LOG6[6]: No peer certificate received 2018.07.05 05:31:02 LOG7[6]: 7 server accept(s) requested 2018.07.05 05:31:02 LOG7[6]: 4 server accept(s) succeeded 2018.07.05 05:31:02 LOG7[6]: 0 server renegotiation(s) requested 2018.07.05 05:31:02 LOG7[6]: 0 session reuse(s) 2018.07.05 05:31:02 LOG7[6]: 4 internal session cache item(s) 2018.07.05 05:31:02 LOG7[6]: 0 internal session cache fill-up(s) 2018.07.05 05:31:02 LOG7[6]: 0 internal session cache miss(es) 2018.07.05 05:31:02 LOG7[6]: 0 external session cache hit(s) 2018.07.05 05:31:02 LOG7[6]: 0 expired session(s) retrieved 2018.07.05 05:31:02 LOG6[6]: TLS accepted: new session negotiated 2018.07.05 05:31:02 LOG6[6]: TLSv1.2 ciphersuite: ECDHE-RSA-AES256-GCM-SHA384 (256-bit encryption) 2018.07.05 05:31:02 LOG7[6]: Compression: null, expansion: null 2018.07.05 05:31:02 LOG6[6]: s_connect: connecting 192.168.112.16:554 2018.07.05 05:31:02 LOG7[6]: s_connect: s_poll_wait 192.168.112.16:554: waiting 10 seconds 2018.07.05 05:31:02 LOG5[6]: s_connect: connected 192.168.112.16:554 2018.07.05 05:31:02 LOG6[6]: persistence: 192.168.112.16:554 cached 2018.07.05 05:31:02 LOG5[6]: Service [rtsp] connected remote server from 192.168.112.16:58596 2018.07.05 05:31:02 LOG7[6]: Setting remote socket options (FD=9) 2018.07.05 05:31:02 LOG7[6]: Option TCP_NODELAY set on remote socket 2018.07.05 05:31:02 LOG7[6]: Remote descriptor (FD=9) initialized 2018.07.05 05:31:02 LOG6[6]: TLS socket closed (SSL_read) 2018.07.05 05:31:02 LOG7[6]: Sent socket write shutdown 2018.07.05 05:31:02 LOG5[6]: Connection closed: 0 byte(s) sent to TLS, 0 byte(s) sent to socket 2018.07.05 05:31:02 LOG7[6]: Remote descriptor (FD=9) closed 2018.07.05 05:31:02 LOG7[6]: Local descriptor (FD=3) closed 2018.07.05 05:31:02 LOG7[6]: Service [rtsp] finished (0 left) 2018.07.05 05:31:05 LOG7[main]: Found 1 ready file descriptor(s) 2018.07.05 05:31:05 LOG7[main]: FD=4 events=0x2001 revents=0x0 2018.07.05 05:31:05 LOG7[main]: FD=7 events=0x2001 revents=0x1

6 12

Fwd: stunnel-users Digest, Vol 168, Issue 2
by Avinash Kumar 05 Jul '18

05 Jul '18

Regards, Avinash Kumar ---------- Forwarded message ---------- From: Avinash Kumar <avinash14331(a)gmail.com> Date: Wed, Jul 4, 2018 at 11:59 AM Subject: Re: [stunnel-users] stunnel-users Digest, Vol 168, Issue 2 To: "Jose Alf." <josealf(a)rocketmail.com> Hi, I commented sslVersion but still getting the same issue. Please find below my configuration details for both client and server: Server conf: Client Conf: Regards, Avinash Kumar On Tue, Jul 3, 2018 at 6:26 PM, Jose Alf. <josealf(a)rocketmail.com> wrote: > Kumar, > > Probably you are trying to connect to a server that dos not allow TLs > v1.0m a protocol that has been deprecated. Please Comment out the > sslVersion line and try again. > > regards, > > Jose > > > > On Tuesday, July 3, 2018, 6:37:53 AM GMT-5, Avinash Kumar < > avinash14331(a)gmail.com> wrote: > > > Hi, > > As requested, Posting my configuration. > [https-App-setup] client = yes accept = 9898 connect = > <<source-ipaddress>>:9898 cert = <<stunnel-installationdirectory>>\config\App\morpheus.pem > key = <<stunnel-installationdirectory>>\config\App\morpheus.key CAfile = > <<stunnel-installationdirectory>>\config\App\root-ca.pem sslVersion = > TLSv1 options = NO_SSLv3 > > > Regards, > Avinash Kumar > > On Tue, Jul 3, 2018 at 3:30 PM, <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 > <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@stunnel. org > <stunnel-users-request(a)stunnel.org> > > You can reach the person managing the list at > stunnel-users-owner@stunnel. org <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. Re: Stunnel Issue (Flo Rance) > > > ------------------------------ ------------------------------ ---------- > > Message: 1 > Date: Tue, 3 Jul 2018 11:18:03 +0200 > From: Flo Rance <trourance(a)gmail.com> > To: Avinash Kumar <avinash14331(a)gmail.com> > Cc: stunnel-users(a)stunnel.org > Subject: Re: [stunnel-users] Stunnel Issue > Message-ID: > <CAHogYcUn6BzfBr75X- DuteetppESv2KOjGJmGO7mc=SuHVaE > Xw(a)mail.gmail.com <SuHVaEXw(a)mail.gmail.com>> > Content-Type: text/plain; charset="utf-8" > > Please post your configuration. Without that, it's not obvious. > > Regards, > Flo > > On Tue, Jul 3, 2018 at 10:42 AM, Avinash Kumar <avinash14331(a)gmail.com> > wrote: > > > Attaching the screenshot > > > > Regards, > > Avinash Kumar > > > > On Tue, Jul 3, 2018 at 2:11 PM, Avinash Kumar <avinash14331(a)gmail.com> > > wrote: > > > >> Hi, > >> > >> I am getting below error while connecting through stunnel: > >> > >> > >> > >> Regards, > >> Avinash Kumar > >> > > > > > > ______________________________ _________________ > > stunnel-users mailing list > > stunnel-users(a)stunnel.org > > https://www.stunnel.org/cgi- bin/mailman/listinfo/stunnel- users > <https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users> > > > > >

3 3

Intermittent error in 042_inetd
by Ian Bamforth 04 Jul '18

04 Jul '18

Afternoon, Until recently we'd disabled `make test` because of certificate problems - we've re-enabled it (using `make check`) but are getting intermittent failures (around 50% of CI runs). Below is the output from the logs - I can't see what's gone wrong, can anyone shed any light? 2018.07.04 09:59:36 LOG7[ui]: Clients allowed=14648 2018.07.04 09:59:36 LOG7[ui]: errno: (*__errno_location ()) 2018.07.04 09:59:36 LOG7[ui]: Compression disabled 2018.07.04 09:59:36 LOG7[ui]: No PRNG seeding was required 2018.07.04 09:59:36 LOG7[ui]: Ciphers: HIGH:!aNULL:!SSLv2:!DH:!kDHEPSK 2018.07.04 09:59:36 LOG7[ui]: TLS options: 0x02004004 (+0x00004000, -0x00000000) 2018.07.04 09:59:36 LOG7[ui]: Private key check succeeded 2018.07.04 09:59:36 LOG7[ui]: ECDH initialization 2018.07.04 09:59:36 LOG7[ui]: ECDH initialized with curve prime256v1 2018.07.04 09:59:36 LOG7[ui]: Binding service [server] 2018.07.04 09:59:36 LOG7[ui]: Listening file descriptor created (FD=6) 2018.07.04 09:59:36 LOG7[ui]: Setting accept socket options (FD=6) 2018.07.04 09:59:36 LOG7[ui]: Option SO_REUSEADDR set on accept socket 2018.07.04 09:59:36 LOG7[main]: Created pid file /opt/stunnel/stunnel-5.48/tests/logs/stunnel.pid 2018.07.04 09:59:36 LOG7[cron]: Cron thread initialized 2018.07.04 09:59:36 LOG7[main]: Found 1 ready file descriptor(s) 2018.07.04 09:59:36 LOG7[main]: FD=4 events=0x2001 revents=0x0 2018.07.04 09:59:36 LOG7[main]: FD=6 events=0x2001 revents=0x1 2018.07.04 09:59:36 LOG7[main]: Service [server] accepted (FD=3) from 127.0.0.1:58890 2018.07.04 09:59:36 LOG7[0]: Service [server] started 2018.07.04 09:59:36 LOG7[0]: Setting local socket options (FD=3) 2018.07.04 09:59:36 LOG7[0]: Option TCP_NODELAY set on local socket 2018.07.04 09:59:36 LOG7[0]: TLS state (accept): before SSL initialization 2018.07.04 09:59:36 LOG7[0]: TLS state (accept): before SSL initialization 2018.07.04 09:59:36 LOG7[0]: SNI: no virtual services defined 2018.07.04 09:59:36 LOG7[0]: TLS state (accept): SSLv3/TLS read client hello 2018.07.04 09:59:36 LOG7[0]: TLS state (accept): SSLv3/TLS write server hello 2018.07.04 09:59:36 LOG7[0]: TLS state (accept): SSLv3/TLS write certificate 2018.07.04 09:59:36 LOG7[0]: TLS state (accept): SSLv3/TLS write key exchange 2018.07.04 09:59:36 LOG7[0]: TLS state (accept): SSLv3/TLS write server done 2018.07.04 09:59:36 LOG7[0]: TLS state (accept): SSLv3/TLS write server done 2018.07.04 09:59:36 LOG7[0]: TLS state (accept): SSLv3/TLS read client key exchange 2018.07.04 09:59:36 LOG7[0]: TLS state (accept): SSLv3/TLS read change cipher spec 2018.07.04 09:59:36 LOG7[0]: TLS state (accept): SSLv3/TLS read finished 2018.07.04 09:59:36 LOG7[0]: TLS state (accept): SSLv3/TLS write change cipher spec 2018.07.04 09:59:36 LOG7[0]: TLS state (accept): SSLv3/TLS write finished 2018.07.04 09:59:36 LOG7[0]: New session callback 2018.07.04 09:59:36 LOG7[0]: 1 server accept(s) requested 2018.07.04 09:59:36 LOG7[0]: 1 server accept(s) succeeded 2018.07.04 09:59:36 LOG7[0]: 0 server renegotiation(s) requested 2018.07.04 09:59:36 LOG7[0]: 0 session reuse(s) 2018.07.04 09:59:36 LOG7[0]: 1 internal session cache item(s) 2018.07.04 09:59:36 LOG7[0]: 0 internal session cache fill-up(s) 2018.07.04 09:59:36 LOG7[0]: 0 internal session cache miss(es) 2018.07.04 09:59:36 LOG7[0]: 0 external session cache hit(s) 2018.07.04 09:59:36 LOG7[0]: 0 expired session(s) retrieved 2018.07.04 09:59:36 LOG7[0]: Compression: null, expansion: null 2018.07.04 09:59:36 LOG7[0]: Setting remote socket options (FD=10) 2018.07.04 09:59:36 LOG7[0]: Option TCP_NODELAY set on remote socket 2018.07.04 09:59:36 LOG7[0]: Remote descriptor (FD=10) initialized 2018.07.04 09:59:36 LOG7[0]: TLS alert (read): warning: close notify 2018.07.04 09:59:36 LOG7[0]: Sent socket write shutdown 2018.07.04 09:59:36 LOG7[0]: Remote descriptor (FD=10) closed 2018.07.04 09:59:36 LOG7[0]: Local descriptor (FD=3) closed 2018.07.04 09:59:36 LOG7[0]: Service [server] finished (0 left) 2018.07.04 09:59:36 LOG7[main]: Found 1 ready file descriptor(s) 2018.07.04 09:59:36 LOG7[main]: FD=4 events=0x2001 revents=0x1 2018.07.04 09:59:36 LOG7[main]: FD=6 events=0x2001 revents=0x0 2018.07.04 09:59:36 LOG7[main]: Dispatching a signal from the signal pipe 2018.07.04 09:59:36 LOG7[main]: Processing SIGCHLD 2018.07.04 09:59:36 LOG7[main]: Retrieving pid statuses with waitpid() 2018.07.04 09:59:36 LOG7[ui]: Clients allowed=14648 2018.07.04 09:59:36 LOG7[ui]: errno: (*__errno_location ()) 2018.07.04 09:59:36 LOG7[ui]: Compression disabled 2018.07.04 09:59:36 LOG7[ui]: No PRNG seeding was required 2018.07.04 09:59:36 LOG7[ui]: Ciphers: HIGH:!aNULL:!SSLv2:!DH:!kDHEPSK 2018.07.04 09:59:36 LOG7[ui]: TLS options: 0x02000004 (+0x00000000, -0x00000000) 2018.07.04 09:59:36 LOG7[ui]: No certificate or private key specified 2018.07.04 09:59:36 LOG7[0]: Service [inetd client] started 2018.07.04 09:59:36 LOG7[0]: s_connect: s_poll_wait 127.0.0.1:4433: waiting 10 seconds 2018.07.04 09:59:36 LOG7[0]: Setting remote socket options (FD=3) 2018.07.04 09:59:36 LOG7[0]: Option TCP_NODELAY set on remote socket 2018.07.04 09:59:36 LOG7[0]: Remote descriptor (FD=3) initialized 2018.07.04 09:59:36 LOG7[0]: TLS state (connect): before SSL initialization 2018.07.04 09:59:36 LOG7[0]: TLS state (connect): SSLv3/TLS write client hello 2018.07.04 09:59:36 LOG7[0]: TLS state (connect): SSLv3/TLS write client hello 2018.07.04 09:59:36 LOG7[0]: TLS state (connect): SSLv3/TLS read server hello 2018.07.04 09:59:36 LOG7[0]: TLS state (connect): SSLv3/TLS read server certificate 2018.07.04 09:59:36 LOG7[0]: TLS state (connect): SSLv3/TLS read server key exchange 2018.07.04 09:59:36 LOG7[0]: TLS state (connect): SSLv3/TLS read server done 2018.07.04 09:59:36 LOG7[0]: TLS state (connect): SSLv3/TLS write client key exchange 2018.07.04 09:59:36 LOG7[0]: TLS state (connect): SSLv3/TLS write change cipher spec 2018.07.04 09:59:36 LOG7[0]: TLS state (connect): SSLv3/TLS write finished 2018.07.04 09:59:36 LOG7[0]: TLS state (connect): SSLv3/TLS write finished 2018.07.04 09:59:36 LOG7[0]: TLS state (connect): SSLv3/TLS read change cipher spec 2018.07.04 09:59:36 LOG7[0]: TLS state (connect): SSLv3/TLS read finished 2018.07.04 09:59:36 LOG7[0]: New session callback 2018.07.04 09:59:36 LOG7[0]: Peer certificate was cached (1241 bytes) 2018.07.04 09:59:36 LOG7[0]: 1 client connect(s) requested 2018.07.04 09:59:36 LOG7[0]: 1 client connect(s) succeeded 2018.07.04 09:59:36 LOG7[0]: 0 client renegotiation(s) requested 2018.07.04 09:59:36 LOG7[0]: 0 session reuse(s) 2018.07.04 09:59:36 LOG7[0]: Compression: null, expansion: null 2018.07.04 09:59:36 LOG7[0]: Sending close_notify alert 2018.07.04 09:59:36 LOG7[0]: TLS alert (write): warning: close notify 2018.07.04 09:59:36 LOG7[0]: Remote descriptor (FD=3) closed 2018.07.04 09:59:36 LOG7[0]: Service [inetd client] finished (0 left) 2018.07.04 09:59:36 LOG7[0]: Deallocating section defaults 2018.07.04 09:59:36 LOG7[main]: Found 1 ready file descriptor(s) 2018.07.04 09:59:36 LOG7[main]: FD=4 events=0x2001 revents=0x1 2018.07.04 09:59:36 LOG7[main]: FD=6 events=0x2001 revents=0x0 2018.07.04 09:59:36 LOG7[main]: Dispatching a signal from the signal pipe 2018.07.04 09:59:36 LOG7[main]: Processing SIGNAL_TERMINATE 2018.07.04 09:59:36 LOG7[main]: Leak detection table utilization: 86/997, 8.63% 2018.07.04 09:59:36 LOG7[main]: Removed pid file /opt/stunnel/stunnel-5.48/tests/logs/stunnel.pid 2018.07.04 09:59:36 LOG7[main]: Deallocating section defaults Regards, Ian Bamforth Senior Software Engineer Operations & Planning Systems Division T: +44 (0)113 344 3970<tel:00441133443970> M: +44 (0)7852 404240<tel:00447852404240> E: Ian.Bamforth(a)tracsis.com<mailto:Ian.Bamforth@tracsis.com> W: www.tracsis.com<https://www.tracsis.com> www.tracsisops.com<http://www.tracsisops.com> Follow Us [https://static.tracsis.com/email/lin2.png]<https://www.linkedin.com/company/972873?trk=tyah&trkInfo=idx:1-1-1,tarId:14…> [https://static.tracsis.com/email/twi2.png] <https://www.twitter.com/tracsis> Tracsis plc Leeds Innovation Centre 103 Clarendon Road Leeds LS2 9DF [https://static.tracsis.com/email/award4.png] Tracsis Operations and Planning Systems Division is a Division of Tracsis plc and comprises Tracsis plc (05019106), Tracsis Rail Consultancy Limited (05047148), Safety Information Systems Limited trading as COMPASS (02588404) and Tracsis Retail and Operations Limited (04225250), all subsidiaries of Tracsis plc with a registered office at Leeds Innovation Centre,103 Clarendon Road, Leeds, LS2 9DF. VAT Registration No: 945 7876 61. This email and its attachments may be confidential and are intended solely for the use of the individual(s) to whom it is addressed. If you are not the intended recipient of this email and its attachments, you must take no action based upon them, nor must you copy or show them to anyone. Please contact the sender if you believe you have received this email in error.

1 0

stunnel on Windows - using CAPI - tls v1.2?==?utf-8?q? ?
by Brian Ipsen 04 Jul '18

04 Jul '18

Hi Does anyone know whether there is a fix pending for being able to use the Windows built-in certificate store (by CAPI) for client authentication - and using TLS v1.2 ? Currently I need to force the stunnel client to use TLS v1.1, as there seem to be a limitation somewhere if using TLS v1.2... Regards Brian

1 0

tls linger
by Daniel Trickett 03 Jul '18

03 Jul '18

Hi, We are using stunnel to allow us to punchout to suppliers using TLS 1.2 protocol. We are seeing the following with this particular supplier. 2018.07.02 08:49:05 LOG6[4]: TLS connected: previous session reused 2018.07.02 08:49:05 LOG6[4]: TLSv1.2 ciphersuite: ECDHE-RSA-AES256-SHA384 (256-bit encryption) 2018.07.02 08:49:05 LOG7[4]: Compression: null, expansion: null 2018.07.02 08:49:15 LOG3[4]: SSL_read: Connection reset by peer (131) 2018.07.02 08:49:15 LOG5[4]: Connection reset: 1720 byte(s) sent to TLS, 0 byte(s) sent to socket 2018.07.02 08:49:15 LOG7[4]: linger (remote): Invalid argument (22) 2018.07.02 08:49:15 LOG7[4]: Remote descriptor (FD=13) closed 2018.07.02 08:49:15 LOG7[4]: Local descriptor (FD=3) closed 2018.07.02 08:49:15 LOG7[4]: Service [dell-https] finished (0 left) We have set socket = l:SO_LINGER=1:60, but still occasionally have an issue. Is there anything else that we may need to set? Since the below is default, would not expect to set it.. socket = a:SO_REUSEADDR=no disable address reuse (enabled by default) 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 http://www.emdgroup.com/emd/imprint/mail_disclaimer.html to access the German, French, Spanish and Portuguese versions of this disclaimer.

1 0

Re: [stunnel-users] stunnel-users Digest, Vol 168, Issue 2
by Avinash Kumar 03 Jul '18

03 Jul '18

Hi, As requested, Posting my configuration. [https-App-setup] client = yes accept = 9898 connect = <<source-ipaddress>>:9898 cert = <<stunnel-installationdirectory>>\config\App\morpheus.pem key = <<stunnel-installationdirectory>>\config\App\morpheus.key CAfile = <<stunnel-installationdirectory>>\config\App\root-ca.pem sslVersion = TLSv1 options = NO_SSLv3 Regards, Avinash Kumar On Tue, Jul 3, 2018 at 3:30 PM, <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. Re: Stunnel Issue (Flo Rance) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 3 Jul 2018 11:18:03 +0200 > From: Flo Rance <trourance(a)gmail.com> > To: Avinash Kumar <avinash14331(a)gmail.com> > Cc: stunnel-users(a)stunnel.org > Subject: Re: [stunnel-users] Stunnel Issue > Message-ID: > <CAHogYcUn6BzfBr75X-DuteetppESv2KOjGJmGO7mc=SuHVaE > Xw(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Please post your configuration. Without that, it's not obvious. > > Regards, > Flo > > On Tue, Jul 3, 2018 at 10:42 AM, Avinash Kumar <avinash14331(a)gmail.com> > wrote: > > > Attaching the screenshot > > > > Regards, > > Avinash Kumar > > > > On Tue, Jul 3, 2018 at 2:11 PM, Avinash Kumar <avinash14331(a)gmail.com> > > wrote: > > > >> Hi, > >> > >> I am getting below error while connecting through stunnel: > >> > >> > >> > >> Regards, > >> Avinash Kumar > >> > > > > > > _______________________________________________ > > stunnel-users mailing list > > stunnel-users(a)stunnel.org > > https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users > > > > >

2 1

Stunnel Issue
by Avinash Kumar 03 Jul '18

03 Jul '18

Hi, I am getting below error while connecting through stunnel: Regards, Avinash Kumar

2 2

stunnel 5.48 released
by Michal Trojnara 02 Jul '18

02 Jul '18

Dear Users, I have released version 5.48 of stunnel. Version 5.48, 2018.07.02, urgency: HIGH * Security bugfixes - Fixed requesting client certificate when specified as a global option. * New features - Certificate subject checks modified to accept certificates if at least one of the specified checks matches. Home page: https://www.stunnel.org/ Download: https://www.stunnel.org/downloads.html SHA-256 hashes: 1011d5a302ce6a227882d094282993a3187250f42f8a801dcc1620da63b2b8df stunnel-5.48.tar.gz eb160fdf28061eb509e09824ab9cd26f4f0ca9be3b90008bba32274d5136c7eb stunnel-5.48-win32-installer.exe 667ee8c8d5440117285eb5a5ddf0d305a6dd1dbb93dcf5b7bac62f84ddba7466 stunnel-5.48-android.zip Best regards, Mike

1 0

tls question
by Daniel Trickett 02 Jul '18

02 Jul '18

Hi, If I use stunnel 5.44, how do I know that the protocol being used is TLS1.2? Is it the default? Working with supplier sites which still accept 1.0/1.1, but want to make sure that I am using 1.2, as they will be disabling the older protocols. 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 http://www.emdgroup.com/emd/imprint/mail_disclaimer.html to access the German, French, Spanish and Portuguese versions of this disclaimer.

4 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