- stunnel-users - stunnel.org

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

Potentially dangerous change of behavior in handling "global option" in stunnel after version 5.45
by Tony Cheneau 29 Jun '18

29 Jun '18

Hello everyone, I was updating my version of stunnel and playing my regression suite and I was surprised to see some tests fail. We usually apply "verify = 2" as global option at the beginning of the configuration file on our stunnel "server" so as to enforce the client certificate verification. So I was a little bit surprise to see I could establish a TLS connection with my test server without providing a client certificate. The "verify = 2" as a "global option" is parsed at some point, because I can trigger an error message if I place a bogus value ("verify = 8"). Yet, it seems to be ignored when accepting connections. If I move the "verify = 2" from the "global option" to a service-level option for a specific service/tunnel, it works as expected (and documented): it rejects my certificate-less client. After a little bit of investigation, I was able to narrow down the change of behavior in version 5.45 (meaning that 5.44 still follow the old behavior). All the newer version follow this new behavior. I haven't seen any public CVS/SVN/git for stunnel, so I was not able to narrow it down further and I could not identify the exact change in the code that modified the behavior. While I understand that this option is documented in the manpage as a service-level option, in practice, "verify" could be used as a global option for years (my oldest documented usage at my company dates back from stunnel 4.54). (I know this option is going to be replaced by verifyChain/requireCert, the observed behavior reported in this email also applies on these options: they can't be applied program wide as a "global option") Am I missing something obvious here ? I haven't seen the change documented in the changelog, so it looks like a regression to me. Thank you in advance (and thank you for the great piece of software, obviously!). Regards, Tony Cheneau

1 0

Re: [stunnel-users] stunnel 5.47 released
by Eric S Eberhard 28 Jun '18

28 Jun '18

Query -- how does this relate to TLSv1.3 and the alpha version (which is not going to work with the final version -- and does not exist I think) -- and what version of openssl do you recommend? Thanks, 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 Michal Trojnara Sent: Friday, June 22, 2018 11:10 PM To: stunnel-users(a)stunnel.org; stunnel-announce(a)stunnel.org; openssl-users(a)openssl.org Subject: [stunnel-users] stunnel 5.47 released Dear Users, I have released version 5.47 of stunnel. Version 5.47, 2018.06.23, urgency: HIGH * New features - Fast add_lock_callback for OpenSSL < 1.1.0. This largely improves performance on heavy load. - Automatic detection of Homebrew OpenSSL. - Clarified port binding error logs. - Various "make test" improvements. * Bugfixes - Fixed a crash on switching to SNI slave sections. Home page: https://www.stunnel.org/ Download: https://www.stunnel.org/downloads.html SHA-256 hashes: c4e675db996eb92beef885f72a3ed8af3c7603fea6b99d2873198dd6c0021d0b stunnel-5.47.tar.gz 985e1d65a3f4a7599cc78630960e1b2c97981f91ce6bc41f2eefcd371b4067a3 stunnel-5.47-win32-installer.exe 309cfb79329448f0c134aece0d10d0737e3728b25c288e9a76650837cd6f839c stunnel-5.47-android.zip Best regards, Mike

1 0

question regarding TLS connection.
by Daniel Trickett 26 Jun '18

26 Jun '18

Hi We are using stunnel 5.44. We are having an issue connecting with a customer who is not supporting TLS 1.1, only 1.2 and 1.3. When I look in the log, I see the following. Why do I see the SSLv3 note in the line? The below leads me to believe that we connect to the customer, but they say that we are not. 2018.06.25 11:37:24 LOG7[7]: TLS state (connect): SSLv3 read server certificate A 2018.06.25 11:37:24 LOG6[7]: Client certificate not requested 2018.06.25 11:37:24 LOG7[7]: TLS state (connect): SSLv3 read server done A 2018.06.25 11:37:24 LOG7[7]: TLS state (connect): SSLv3 write client key exchange A 2018.06.25 11:37:24 LOG7[7]: TLS state (connect): SSLv3 write change cipher spec A 2018.06.25 11:37:24 LOG7[7]: TLS state (connect): SSLv3 write finished A 2018.06.25 11:37:24 LOG7[7]: TLS state (connect): SSLv3 flush data 2018.06.25 11:37:24 LOG7[7]: TLS state (connect): SSLv3 read finished A 2018.06.25 11:37:24 LOG7[7]: 1 client connect(s) requested 2018.06.25 11:37:24 LOG7[7]: 1 client connect(s) succeeded 2018.06.25 11:37:24 LOG7[7]: 0 client renegotiation(s) requested 2018.06.25 11:37:24 LOG7[7]: 0 session reuse(s) 2018.06.25 11:37:24 LOG6[7]: TLS connected: new session negotiated Best regards, Dan Daniel Trickett Head of Database Services | MBS Business Technology BX-TCS-O Oracle ERP Business Services of Merck KGaA, Darmstadt, Germany Planned Absence - 7/2/2018 - 7/6/2018 MilliporeSigma A business of Merck KGaA, Darmstadt, Germany EMD Millipore Corporation | 80 Ashby Road | Bedford, MA 01730 | USA office 781-533-3017 |cell 978-761-3506 |email daniel.trickett(a)emdmillipore.com<mailto:daniel.trickett@emdmillipore.com> 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.

2 1

stunnel 5.47 released
by Michal Trojnara 23 Jun '18

23 Jun '18

Dear Users, I have released version 5.47 of stunnel. Version 5.47, 2018.06.23, urgency: HIGH * New features - Fast add_lock_callback for OpenSSL < 1.1.0. This largely improves performance on heavy load. - Automatic detection of Homebrew OpenSSL. - Clarified port binding error logs. - Various "make test" improvements. * Bugfixes - Fixed a crash on switching to SNI slave sections. Home page: https://www.stunnel.org/ Download: https://www.stunnel.org/downloads.html SHA-256 hashes: c4e675db996eb92beef885f72a3ed8af3c7603fea6b99d2873198dd6c0021d0b stunnel-5.47.tar.gz 985e1d65a3f4a7599cc78630960e1b2c97981f91ce6bc41f2eefcd371b4067a3 stunnel-5.47-win32-installer.exe 309cfb79329448f0c134aece0d10d0737e3728b25c288e9a76650837cd6f839c stunnel-5.47-android.zip Best regards, Mike

2 1

Stunnel 5.45 and 5.46 crashes upon reconnect HTTPS
by Javier 22 Jun '18

22 Jun '18

Hi, isn't annoying when you are using an old version, 5.44, and all goes fine, you notice you are outdated and then comes the problems after update? :-P The thing is that yesterday I needed the HTTPS server so I run Stunnel 5.44 for my non-SSL app and all was fine. I updated to 5.46 just because I forgot the last time and didn't even run again because I didn't need it. Today I used it and... I had a crash. I tested 5.45 to trace versions back, and it crashes as well. Back to 5.44 and no crash. The crash happens when there is a reload/reconnect/multiconnect (example, 2 connections html+images) by the browser when connects to an HTTPS server. It only happens when using a SNI service. I've been able to trace back the log on those versions and when fails in 5.45 and 5.46 is at the time when it needs to switch to the SNI service. (log from 5.44) SNI: requested servername: xxx SNI: matched pattern: xxx SNI: switched to service [xxx] <<<<----- BEFORE SWITCH, IT CRASHES on 5.45 and 5.46 Imagine you load https://xxx/. The first time is fine, the second, crashes stunnel. Not happening with 5.44. I haven't seen any change to SNI in manual so... :-? These are the configs for the used virtual servers. Nothing has been changed, anyway: [SSL] client = no accept = y.y.y.1:4747 connect = y.y.y.2:443 [SSL-xxx-SNI] client = no sni = SSL:xxx connect = y.y.y.2:443 cert = pem key = pem Don't mind the port numbers. They aren't in conflict. Running on Windows 2000. Regards.

3 4