Ok, so the problem is similar on Linux also? In my case 5.44 works well without crashes, only 5.45 and 5.46 is broken on Windows.
Den fre 22 juni 2018 15:55Mark Brookes <[email protected]> skrev: > We have just hit the same problem with 5.45. 5.41 does not appear to > exhibit the same issue. > > The problem appears to be linked to the client/session. > Using sni if we hit the url with one client the page loads fine, if we hit > stunnel with a second connection from another client on a different IP > their page reloads fine. But if we reload either of those pages stunnel > segfaults with the following message - > > Jun 22 11:42:31 lbmaster kernel: stunnel[6510]: segfault at 178 ip > 00007fc64fcb5fe0 sp 00007fc6500f5948 error 4 in > libssl.so.1.0.0[7fc64fc75000+65000] > > The above was generated with stunnel 5.45 and openssl 1.0.2j-fips. I also > tested it with stunnel built against 1.1.0h and had the same issue. > Below is the config - > pid = /var/run/stunnel/stunnel.pid > debug = local1.0 > socket = a:IP_FREEBIND=yes > fips = no > sslVersion = all > > [VIP_Name-1] > cert = /etc/loadbalancer.org/certs/sslcert1/sslcert1.pem > ciphers = > ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DHE-RSA-AES256-SHA256:!RC4:!MD5:!aNULL:!EDH:!3DES > accept = 192.168.0.112:443 > connect = 192.168.0.112:80 > delay = yes > options = NO_SSLv3 > options = NO_TLSv1 > options = NO_TLSv1.1 > options = DONT_INSERT_EMPTY_FRAGMENTS > renegotiation = no > local = 192.168.0.112 > TIMEOUTclose = 0 > [fizzygood] > sni = VIP_Name-1:lb1.testdomain.co.uk > cert = /etc/loadbalancer.org/certs/sslcert1/sslcert1.pem > ciphers = > ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DHE-RSA-AES256-SHA256:!RC4:!MD5:!aNULL:!EDH:!3DES > connect = 192.168.0.112:80 > delay = yes > options = NO_SSLv3 > options = NO_TLSv1 > options = DONT_INSERT_EMPTY_FRAGMENTS > renegotiation = no > local = 192.168.0.112 > > On Thu, 21 Jun 2018 at 20:08, Per Salmi <[email protected]> wrote: > >> I have exactly the same problem with stunnel 5.45 and 5.46 crashing on >> second request! >> >> Running on Windows 10 Pro x64 1803. >> >> I also use https to separate traffic to two different sites on the same >> server as the stunnel service. >> >> /Per >> >> Den tor 21 juni 2018 19:04Javier <[email protected]> skrev: >> >>> 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. >>> _______________________________________________ >>> stunnel-users mailing list >>> [email protected] >>> https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users >>> >> _______________________________________________ >> stunnel-users mailing list >> [email protected] >> https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users >> > > > -- > > Mark Brookes > Loadbalancer.org Ltd. > www.loadbalancer.org > > > +44 (0)330 380 1064 > [email protected] >
_______________________________________________ stunnel-users mailing list [email protected] https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
