Re: Haproxy 1.8 with OpenSSL 1.1.1-pre4 stops working after 1 hour

[Emeric Brun]

Hi Lukas,

On 06/27/2018 04:48 AM, Willy Tarreau wrote:
> On Wed, Jun 27, 2018 at 01:44:08AM +0200, Lukas Tribus wrote:
>> Hey guys,
>>
>>
>> FYI after lots of discussions with openssl folks:
>>
>> https://github.com/openssl/openssl/issues/5330
>> https://github.com/openssl/openssl/pull/6388
>> https://github.com/openssl/openssl/pull/6432
>>
>>
>> OpenSSL 1.1.1 will now keep the FD open by default:
>>
>> https://github.com/openssl/openssl/commit/c7504aeb640a88949dfe3146f7e0f275f517464c
> 
> Wow good job Lukas! At least now we know that openssl 1.1.1 is not broken
> anymore! Thanks for taking care of explaining all these valid use cases
> there!
> 
> Willy
> 

I've noticed that. Thank you for your support reporting this issue to openssl's 
team

R,
Emeric

Re: Haproxy 1.8 with OpenSSL 1.1.1-pre4 stops working after 1 hour

[Willy Tarreau]

On Wed, Jun 27, 2018 at 01:44:08AM +0200, Lukas Tribus wrote:
> Hey guys,
> 
> 
> FYI after lots of discussions with openssl folks:
> 
> https://github.com/openssl/openssl/issues/5330
> https://github.com/openssl/openssl/pull/6388
> https://github.com/openssl/openssl/pull/6432
> 
> 
> OpenSSL 1.1.1 will now keep the FD open by default:
> 
> https://github.com/openssl/openssl/commit/c7504aeb640a88949dfe3146f7e0f275f517464c

Wow good job Lukas! At least now we know that openssl 1.1.1 is not broken
anymore! Thanks for taking care of explaining all these valid use cases
there!

Willy

Re: Haproxy 1.8 with OpenSSL 1.1.1-pre4 stops working after 1 hour

[Lukas Tribus]

Hey guys,


FYI after lots of discussions with openssl folks:

https://github.com/openssl/openssl/issues/5330
https://github.com/openssl/openssl/pull/6388
https://github.com/openssl/openssl/pull/6432


OpenSSL 1.1.1 will now keep the FD open by default:

https://github.com/openssl/openssl/commit/c7504aeb640a88949dfe3146f7e0f275f517464c


cheers,
lukas

Re: Haproxy 1.8 with OpenSSL 1.1.1-pre4 stops working after 1 hour

[Emeric Brun]

Hi Lukas,

On 05/24/2018 11:27 AM, Lukas Tribus wrote:
> Hi Emeric,
> 
> 
> On 24 May 2018 at 11:19, Emeric Brun  wrote:
>> in pre6 there is a news wrapping function on getrandom which have different 
>> fallback way to use the syscall.
>>
>> Perhaps the openssl -r output depends of that (if getrandom was found from 
>> glibc or if a syscall loaded from a different way and considered 
>> os-specific).
> 
> No, openssl version -r output is a verbatim copy of what was passed to
> --with-rand-seed at configure time:
> https://github.com/openssl/openssl/pull/5910#issuecomment-391514494
> 
> 
>> @Lukas Which build-workarround did you use?
> 
> No workaround at all, getrandom works for me out of the box in -pre6
> (with libc2.23) and the output of "openssl version -r" is
> "os-specific", which also is expected behavior as per the github
> discussion above. The raw syscall as implemented in-pre6 works for me.

Ok, i've initialy patched the pre3, and port my patch on pre6 in a different 
way but i didn't check if it work of the box in pre6 :)

In my case i'm using cross-compilation and there is not access to kernel 
includes, only those of the builded libc of the sysroot.

This way i don't now how openssl building will be able to retrieve the 
SYS_getrandom not the syscall def because the are not present in my sysroot.

Anyway, it seems that there was two issues in that thread, do still have one 
Lukas?


R,
Emeric

Re: Haproxy 1.8 with OpenSSL 1.1.1-pre4 stops working after 1 hour

[Lukas Tribus]

Hi Emeric,


On 24 May 2018 at 11:19, Emeric Brun  wrote:
> in pre6 there is a news wrapping function on getrandom which have different 
> fallback way to use the syscall.
>
> Perhaps the openssl -r output depends of that (if getrandom was found from 
> glibc or if a syscall loaded from a different way and considered os-specific).

No, openssl version -r output is a verbatim copy of what was passed to
--with-rand-seed at configure time:
https://github.com/openssl/openssl/pull/5910#issuecomment-391514494


> @Lukas Which build-workarround did you use?

No workaround at all, getrandom works for me out of the box in -pre6
(with libc2.23) and the output of "openssl version -r" is
"os-specific", which also is expected behavior as per the github
discussion above. The raw syscall as implemented in-pre6 works for me.


Lukas

Re: Haproxy 1.8 with OpenSSL 1.1.1-pre4 stops working after 1 hour

[Emeric Brun]

Hi Lukas,

On 05/23/2018 09:48 PM, Lukas Tribus wrote:
> Hello,
> 
> 
> On 23 May 2018 at 18:29, Emeric Brun  wrote:
>> This issue was due to openssl-1.1.1 which re-seed after an elapsed time or 
>> number of request.
>>
>> If /dev/urandom is used as seeding source when haproxy is chrooted it fails 
>> to re-open /dev/urandom 
>>
>> By defaut the openssl-1.1.1 configure script uses the syscall getrandom as 
>> seeding source and fallback on /dev/urandom if not available.
>>
>> So you don't face the issue if your openssl-1.1.1 is compiled to use 
>> getrandom
>>
>> But getrandom syscall is available only since kernel > 3.17 and the main 
>> point: for glibc > 2.25.
>>
>> With openssl-1.1.1 you can check this this way:
>> # ./openssl-1.1.1/openssl version -r
>> Seeding source: getrandom-syscall
> 
> I have glibc 2.23 (Ubuntu 16.04) and openssl shows "os-specific", even
> if kernel headers are installed while compiling, yet -pre6 does not
> hang for me in chroot (-pre4 did):
> 
> lukas@dev:~/libsslbuild/bin$ uname -r
> 4.4.0-109-generic
> lukas@dev:~/libsslbuild/bin$ ./openssl version
> OpenSSL 1.1.1-pre6 (beta) 1 May 2018
> lukas@dev:~/libsslbuild/bin$ ./openssl version -r
> Seeding source: os-specific
> lukas@dev:~/libsslbuild/bin$
> 
> 
> But, stracing haproxy shows that the library IS ACTUALLY using
> getrandom(). So the "Seeding source" output of the executable is
> wrong. Gonna dig into this as well, but seeing how my haproxy
> executable uses getrandom() calls, this perfectly explains why I did
> not see this in -pre6 (which has the build-workaround for < libc 2.25,
> while pre4 did not, so it did not use the getrandom() call).

in pre6 there is a news wrapping function on getrandom which have different 
fallback way to use the syscall.

Perhaps the openssl -r output depends of that (if getrandom was found from 
glibc or if a syscall loaded from a different way and considered os-specific).

@Lukas Which build-workarround did you use?

In my case i've patched openssl to define SYS_getrandom (depending of the arch) 
and i set --with-rand-seed=getrandom

You may have a more elegant way to do that without a patch.

/*
 * syscall_random(): Try to get random data using a system call
 * returns the number of bytes returned in buf, or <= 0 on error.
 */
int syscall_random(void *buf, size_t buflen)
{
#  if defined(OPENSSL_HAVE_GETRANDOM)
return (int)getrandom(buf, buflen, 0);
#  endif

#  if defined(__linux) && defined(SYS_getrandom)
return (int)syscall(SYS_getrandom, buf, buflen, 0);
#  endif

#  if defined(__FreeBSD__) && defined(KERN_ARND)
return (int)sysctl_random(buf, buflen);
#  endif

   /* Supported since OpenBSD 5.6 */
#  if defined(__OpenBSD__) && OpenBSD >= 201411
return getentropy(buf, buflen);
#  endif

return -1;
}

My patch:
--- openssl-1.1.1-pre6/crypto/rand/rand_unix.c.ori  2018-05-22 
14:06:03.490771549 +0200
+++ openssl-1.1.1-pre6/crypto/rand/rand_unix.c  2018-05-22 14:14:33.133237079 
+0200
@@ -173,6 +173,26 @@
 #   define OPENSSL_HAVE_GETRANDOM
 #  endif

+# if defined(__linux)
+#   include 
+#if !defined(SYS_getrandom)
+#if !defined(__NR_getrandom)
+#if defined(__powerpc__) || defined(__powerpc64__)
+#define __NR_getrandom 236
+#elif defined(__sparc__) || defined(__sparc64__)
+#define __NR_getrandom 347 
+#elif defined(__x86_64__)
+#define __NR_getrandom 318
+#elif defined (__i386__)
+#define __NR_getrandom 355
+#elif defined (__s390__) || defined(__s390x__)
+#define __NR_getrandom 249
+#endif /* $arch */
+#endif /* __NR_getrandom */
+#   define SYS_getrandom __NR_getrandom
+#endif
+#endif
+
 #  if defined(OPENSSL_HAVE_GETRANDOM)
 #   include 
 #  endif
~


> 
> 
> @Sander it looks like openssl folks won't change their mind about
> this. You have to either upgrade to a kernel more recent than 3.17 so
> that getrandom() can be used, or make /dev/xrandom available within
> your chroot.
> 
> 
> 
> Lukas
> 

Emeric

Re: Haproxy 1.8 with OpenSSL 1.1.1-pre4 stops working after 1 hour

[Sander Hoentjen]

On 05/23/2018 09:48 PM, Lukas Tribus wrote:
> Hello,
>
>
> On 23 May 2018 at 18:29, Emeric Brun  wrote:
>> This issue was due to openssl-1.1.1 which re-seed after an elapsed time or 
>> number of request.
>>
>> If /dev/urandom is used as seeding source when haproxy is chrooted it fails 
>> to re-open /dev/urandom 
>>
>> By defaut the openssl-1.1.1 configure script uses the syscall getrandom as 
>> seeding source and fallback on /dev/urandom if not available.
>>
>> So you don't face the issue if your openssl-1.1.1 is compiled to use 
>> getrandom
>>
>> But getrandom syscall is available only since kernel > 3.17 and the main 
>> point: for glibc > 2.25.
>>
>> With openssl-1.1.1 you can check this this way:
>> # ./openssl-1.1.1/openssl version -r
>> Seeding source: getrandom-syscall
> I have glibc 2.23 (Ubuntu 16.04) and openssl shows "os-specific", even
> if kernel headers are installed while compiling, yet -pre6 does not
> hang for me in chroot (-pre4 did):
>
> lukas@dev:~/libsslbuild/bin$ uname -r
> 4.4.0-109-generic
> lukas@dev:~/libsslbuild/bin$ ./openssl version
> OpenSSL 1.1.1-pre6 (beta) 1 May 2018
> lukas@dev:~/libsslbuild/bin$ ./openssl version -r
> Seeding source: os-specific
> lukas@dev:~/libsslbuild/bin$
>
>
> But, stracing haproxy shows that the library IS ACTUALLY using
> getrandom(). So the "Seeding source" output of the executable is
> wrong. Gonna dig into this as well, but seeing how my haproxy
> executable uses getrandom() calls, this perfectly explains why I did
> not see this in -pre6 (which has the build-workaround for < libc 2.25,
> while pre4 did not, so it did not use the getrandom() call).
>
>
> @Sander it looks like openssl folks won't change their mind about
> this. You have to either upgrade to a kernel more recent than 3.17 so
> that getrandom() can be used, or make /dev/xrandom available within
> your chroot.
When I make /dev/*random available in the chroot, indeed it works fine.
Thanks guys!
As you all have guessed, I am indeed running an older kernel that
doesn't have the getrandom syscall.

Regards,
Sander

Re: Haproxy 1.8 with OpenSSL 1.1.1-pre4 stops working after 1 hour

[Lukas Tribus]

Hello,


On 23 May 2018 at 22:17, Jim Freeman  wrote:
> Or kludge around it with eg; http://www.issihosts.com/haveged/ ?

No, it's not about insufficient entropy in the kernel. It's about
interfacing with that entropy while in chroot.


Lukas

Re: Haproxy 1.8 with OpenSSL 1.1.1-pre4 stops working after 1 hour

[Jim Freeman]

Or kludge around it with eg; http://www.issihosts.com/haveged/ ?

On Wed, May 23, 2018 at 1:48 PM, Lukas Tribus  wrote:

> Hello,
>
>
> On 23 May 2018 at 18:29, Emeric Brun  wrote:
> > This issue was due to openssl-1.1.1 which re-seed after an elapsed time
> or number of request.
> >
> > If /dev/urandom is used as seeding source when haproxy is chrooted it
> fails to re-open /dev/urandom 
> >
> > By defaut the openssl-1.1.1 configure script uses the syscall getrandom
> as seeding source and fallback on /dev/urandom if not available.
> >
> > So you don't face the issue if your openssl-1.1.1 is compiled to use
> getrandom
> >
> > But getrandom syscall is available only since kernel > 3.17 and the main
> point: for glibc > 2.25.
> >
> > With openssl-1.1.1 you can check this this way:
> > # ./openssl-1.1.1/openssl version -r
> > Seeding source: getrandom-syscall
>
> I have glibc 2.23 (Ubuntu 16.04) and openssl shows "os-specific", even
> if kernel headers are installed while compiling, yet -pre6 does not
> hang for me in chroot (-pre4 did):
>
> lukas@dev:~/libsslbuild/bin$ uname -r
> 4.4.0-109-generic
> lukas@dev:~/libsslbuild/bin$ ./openssl version
> OpenSSL 1.1.1-pre6 (beta) 1 May 2018
> lukas@dev:~/libsslbuild/bin$ ./openssl version -r
> Seeding source: os-specific
> lukas@dev:~/libsslbuild/bin$
>
>
> But, stracing haproxy shows that the library IS ACTUALLY using
> getrandom(). So the "Seeding source" output of the executable is
> wrong. Gonna dig into this as well, but seeing how my haproxy
> executable uses getrandom() calls, this perfectly explains why I did
> not see this in -pre6 (which has the build-workaround for < libc 2.25,
> while pre4 did not, so it did not use the getrandom() call).
>
>
> @Sander it looks like openssl folks won't change their mind about
> this. You have to either upgrade to a kernel more recent than 3.17 so
> that getrandom() can be used, or make /dev/xrandom available within
> your chroot.
>
>
>
> Lukas
>
>

Re: Haproxy 1.8 with OpenSSL 1.1.1-pre4 stops working after 1 hour

[Lukas Tribus]

Hello,


On 23 May 2018 at 18:29, Emeric Brun  wrote:
> This issue was due to openssl-1.1.1 which re-seed after an elapsed time or 
> number of request.
>
> If /dev/urandom is used as seeding source when haproxy is chrooted it fails 
> to re-open /dev/urandom 
>
> By defaut the openssl-1.1.1 configure script uses the syscall getrandom as 
> seeding source and fallback on /dev/urandom if not available.
>
> So you don't face the issue if your openssl-1.1.1 is compiled to use getrandom
>
> But getrandom syscall is available only since kernel > 3.17 and the main 
> point: for glibc > 2.25.
>
> With openssl-1.1.1 you can check this this way:
> # ./openssl-1.1.1/openssl version -r
> Seeding source: getrandom-syscall

I have glibc 2.23 (Ubuntu 16.04) and openssl shows "os-specific", even
if kernel headers are installed while compiling, yet -pre6 does not
hang for me in chroot (-pre4 did):

lukas@dev:~/libsslbuild/bin$ uname -r
4.4.0-109-generic
lukas@dev:~/libsslbuild/bin$ ./openssl version
OpenSSL 1.1.1-pre6 (beta) 1 May 2018
lukas@dev:~/libsslbuild/bin$ ./openssl version -r
Seeding source: os-specific
lukas@dev:~/libsslbuild/bin$


But, stracing haproxy shows that the library IS ACTUALLY using
getrandom(). So the "Seeding source" output of the executable is
wrong. Gonna dig into this as well, but seeing how my haproxy
executable uses getrandom() calls, this perfectly explains why I did
not see this in -pre6 (which has the build-workaround for < libc 2.25,
while pre4 did not, so it did not use the getrandom() call).


@Sander it looks like openssl folks won't change their mind about
this. You have to either upgrade to a kernel more recent than 3.17 so
that getrandom() can be used, or make /dev/xrandom available within
your chroot.



Lukas

Re: Haproxy 1.8 with OpenSSL 1.1.1-pre4 stops working after 1 hour

[Emeric Brun]

Hi Sander, Lukas,

On 05/23/2018 02:32 PM, Lukas Tribus wrote:
> Hello,
> 
> On 23 May 2018 at 13:10, Sander Hoentjen  wrote:
>> I can confirm the issue is gone when I don't use chroot. I will try to
>> see if I can get more info like a strace soon. I won't be able to today
>> though. Thanks Lucas and Emeric!
> 
> 1.8.9 with 1.1.1-pre6 chrooted is now running for me for more than 22
> hours. I don't see the same issue.
> 
> So are probably we are facing a different issue.
> 
> 
> 
> Lukas
> 

This issue was due to openssl-1.1.1 which re-seed after an elapsed time or 
number of request.

If /dev/urandom is used as seeding source when haproxy is chrooted it fails to 
re-open /dev/urandom 

By defaut the openssl-1.1.1 configure script uses the syscall getrandom as 
seeding source and fallback on /dev/urandom if not available.

So you don't face the issue if your openssl-1.1.1 is compiled to use getrandom

But getrandom syscall is available only since kernel > 3.17 and the main point: 
for glibc > 2.25.

With openssl-1.1.1 you can check this this way:
# ./openssl-1.1.1/openssl version -r
Seeding source: getrandom-syscall


R,
Emeric

Re: Haproxy 1.8 with OpenSSL 1.1.1-pre4 stops working after 1 hour

[Lukas Tribus]

Hello,

On 23 May 2018 at 13:10, Sander Hoentjen  wrote:
> I can confirm the issue is gone when I don't use chroot. I will try to
> see if I can get more info like a strace soon. I won't be able to today
> though. Thanks Lucas and Emeric!

1.8.9 with 1.1.1-pre6 chrooted is now running for me for more than 22
hours. I don't see the same issue.

So are probably we are facing a different issue.



Lukas

Re: Haproxy 1.8 with OpenSSL 1.1.1-pre4 stops working after 1 hour

[Sander Hoentjen]

On 05/22/2018 04:31 PM, Sander Hoentjen wrote:
> On 05/22/2018 04:19 PM, Emeric Brun wrote:
>> Hi Sander,
>>
>> On 05/22/2018 02:04 PM, Sander Hoentjen wrote:
>>> On 05/22/2018 12:04 PM, Lukas Tribus wrote:
 Hello,

 On 22 May 2018 at 11:48, Sander Hoentjen  wrote:
> I did, but I still experience the same issues. What is your exact
> haproxy version you tested with? Mine is 1.8.8
> Built with OpenSSL version : OpenSSL 1.1.1-pre6 (beta) 1 May 2018
> Running on OpenSSL version : OpenSSL 1.1.1-pre6 (beta) 1 May 2018
 I'm using the development tree. So if it doesn't depend on openssl, it
 may be bug that has been fixed in haproxy itself.

 Can you try 1.8.9?
>>> I just tried HA-Proxy version 1.8.9-83616ec 2018/05/18, it has the same
>>> issue unfortunately.
>>>
>> Do you use chroot ?
>>
>> I remember a behavior change between 1.1.0 and 1.1.1. After an elapsed time 
>> (or a number of new sess) openssl
>> try to re-open some /dev/Xrandom sources. And it could fail in a chroot.
>>
>> https://github.com/openssl/openssl/issues/5330
>>
>>
> Thanks, I do use chroot. In that issue it is mentioned that this problem
> has been fixed, but I will test without chroot anyway. Will report
> tomorrow if this worked or not.
I can confirm the issue is gone when I don't use chroot. I will try to
see if I can get more info like a strace soon. I won't be able to today
though. Thanks Lucas and Emeric!

Re: Haproxy 1.8 with OpenSSL 1.1.1-pre4 stops working after 1 hour

[Sander Hoentjen]

On 05/22/2018 04:19 PM, Emeric Brun wrote:
> Hi Sander,
>
> On 05/22/2018 02:04 PM, Sander Hoentjen wrote:
>> On 05/22/2018 12:04 PM, Lukas Tribus wrote:
>>> Hello,
>>>
>>> On 22 May 2018 at 11:48, Sander Hoentjen  wrote:
 I did, but I still experience the same issues. What is your exact
 haproxy version you tested with? Mine is 1.8.8
 Built with OpenSSL version : OpenSSL 1.1.1-pre6 (beta) 1 May 2018
 Running on OpenSSL version : OpenSSL 1.1.1-pre6 (beta) 1 May 2018
>>> I'm using the development tree. So if it doesn't depend on openssl, it
>>> may be bug that has been fixed in haproxy itself.
>>>
>>> Can you try 1.8.9?
>> I just tried HA-Proxy version 1.8.9-83616ec 2018/05/18, it has the same
>> issue unfortunately.
>>
> Do you use chroot ?
>
> I remember a behavior change between 1.1.0 and 1.1.1. After an elapsed time 
> (or a number of new sess) openssl
> try to re-open some /dev/Xrandom sources. And it could fail in a chroot.
>
> https://github.com/openssl/openssl/issues/5330
>
>
Thanks, I do use chroot. In that issue it is mentioned that this problem
has been fixed, but I will test without chroot anyway. Will report
tomorrow if this worked or not.

Re: Haproxy 1.8 with OpenSSL 1.1.1-pre4 stops working after 1 hour

[Emeric Brun]

Hi Sander,

On 05/22/2018 02:04 PM, Sander Hoentjen wrote:
> On 05/22/2018 12:04 PM, Lukas Tribus wrote:
>> Hello,
>>
>> On 22 May 2018 at 11:48, Sander Hoentjen  wrote:
>>> I did, but I still experience the same issues. What is your exact
>>> haproxy version you tested with? Mine is 1.8.8
>>> Built with OpenSSL version : OpenSSL 1.1.1-pre6 (beta) 1 May 2018
>>> Running on OpenSSL version : OpenSSL 1.1.1-pre6 (beta) 1 May 2018
>> I'm using the development tree. So if it doesn't depend on openssl, it
>> may be bug that has been fixed in haproxy itself.
>>
>> Can you try 1.8.9?
> I just tried HA-Proxy version 1.8.9-83616ec 2018/05/18, it has the same
> issue unfortunately.
> 

Do you use chroot ?

I remember a behavior change between 1.1.0 and 1.1.1. After an elapsed time (or 
a number of new sess) openssl
try to re-open some /dev/Xrandom sources. And it could fail in a chroot.

https://github.com/openssl/openssl/issues/5330

 
Emeric

Re: Haproxy 1.8 with OpenSSL 1.1.1-pre4 stops working after 1 hour

[Sander Hoentjen]

On 05/22/2018 12:04 PM, Lukas Tribus wrote:
> Hello,
>
> On 22 May 2018 at 11:48, Sander Hoentjen  wrote:
>> I did, but I still experience the same issues. What is your exact
>> haproxy version you tested with? Mine is 1.8.8
>> Built with OpenSSL version : OpenSSL 1.1.1-pre6 (beta) 1 May 2018
>> Running on OpenSSL version : OpenSSL 1.1.1-pre6 (beta) 1 May 2018
> I'm using the development tree. So if it doesn't depend on openssl, it
> may be bug that has been fixed in haproxy itself.
>
> Can you try 1.8.9?
I just tried HA-Proxy version 1.8.9-83616ec 2018/05/18, it has the same
issue unfortunately.

Re: Haproxy 1.8 with OpenSSL 1.1.1-pre4 stops working after 1 hour

[Lukas Tribus]

Hello,

On 22 May 2018 at 11:48, Sander Hoentjen  wrote:
> I did, but I still experience the same issues. What is your exact
> haproxy version you tested with? Mine is 1.8.8
> Built with OpenSSL version : OpenSSL 1.1.1-pre6 (beta) 1 May 2018
> Running on OpenSSL version : OpenSSL 1.1.1-pre6 (beta) 1 May 2018

I'm using the development tree. So if it doesn't depend on openssl, it
may be bug that has been fixed in haproxy itself.

Can you try 1.8.9?


Lukas

Re: Haproxy 1.8 with OpenSSL 1.1.1-pre4 stops working after 1 hour

[Sander Hoentjen]

On 05/19/2018 04:55 PM, Lukas Tribus wrote:
> Hello,
>
>
> On 19 April 2018 at 11:09, Sander Hoentjen  wrote:
>> I just tried 1.1.1-pre5, and I still have the same issue.
> I'm running 1.1.1-pre6 now with good results. You may want to check that out.
I did, but I still experience the same issues. What is your exact
haproxy version you tested with? Mine is 1.8.8
Built with OpenSSL version : OpenSSL 1.1.1-pre6 (beta) 1 May 2018
Running on OpenSSL version : OpenSSL 1.1.1-pre6 (beta) 1 May 2018

-- 
Sander

Re: Haproxy 1.8 with OpenSSL 1.1.1-pre4 stops working after 1 hour

[Lukas Tribus]

Hello,


On 19 April 2018 at 11:09, Sander Hoentjen  wrote:
> I just tried 1.1.1-pre5, and I still have the same issue.

I'm running 1.1.1-pre6 now with good results. You may want to check that out.


cheers,
lukas

Re: Haproxy 1.8 with OpenSSL 1.1.1-pre4 stops working after 1 hour

[Sander Hoentjen]

Hi Lucas,

On 04/17/2018 04:27 PM, Lukas Tribus wrote:
> Hello Sander,
>
>
> On 16 April 2018 at 10:55, Sander Hoentjen  wrote:
>> Reading my email again it looks like somehow I messed up part of it,
>> retrying:
>>
>> Hi all,
>>
>> I built Haproxy (1.8.7) against openssl 1.1.1-pre4, and now after 1 hour
>> running haproxy stops accepting new SSL connections.
> I have seen something like that a few weeks ago as well, but I've
> reverted to openssl stable, as I did not have time to get involved
> with troubleshooting openssl master at this point.
>
>
> That having said you may want to retry with latest 1.1.1-pre5, it may
> have been already fixed (Prevent a possible recursion in ERR_get_state
> ...).
I just tried 1.1.1-pre5, and I still have the same issue. What do you
think, is it better to report to the openssl team, or here? I have no
idea where the issue is coming from, but I was hoping the "broken after
exactly 1 hour" would ring some bells.

Sander

Re: Haproxy 1.8 with OpenSSL 1.1.1-pre4 stops working after 1 hour

[Lukas Tribus]

Hello Sander,


On 16 April 2018 at 10:55, Sander Hoentjen  wrote:
> Reading my email again it looks like somehow I messed up part of it,
> retrying:
>
> Hi all,
>
> I built Haproxy (1.8.7) against openssl 1.1.1-pre4, and now after 1 hour
> running haproxy stops accepting new SSL connections.

I have seen something like that a few weeks ago as well, but I've
reverted to openssl stable, as I did not have time to get involved
with troubleshooting openssl master at this point.


That having said you may want to retry with latest 1.1.1-pre5, it may
have been already fixed (Prevent a possible recursion in ERR_get_state
...).



Lukas

Re: Haproxy 1.8 with OpenSSL 1.1.1-pre4 stops working after 1 hour

[Sander Hoentjen]

Reading my email again it looks like somehow I messed up part of it,
retrying:

Hi all,

I built Haproxy (1.8.7) against openssl 1.1.1-pre4, and now after 1 hour
running haproxy stops accepting new SSL connections. When I restart it
works again for almost(?) exactly 1 hour, then stops. Any idea what
might be causing this, or where I should look? Especially the part that
it works for one hour seems weird to me. Next to that, only SSL
connections stop working, the plain ones continue to work. The setup has
one frontend that accepts both http and https, using:
    tcp-request inspect-delay 500ms
    tcp-request content accept if HTTP
    tcp-request content accept if { req.ssl_hello_type 1 }
Maybe this has something to do with it?
Exactly the same config, with only difference being built agains openssl
1.1.0 works without any issues.

Any help appreciated.

Regards,
Sander


On 04/13/2018 10:27 AM, Sander Hoentjen wrote:
> Hi all,
>
> I built Haproxy (1.8.7) against openssl 1.1.1-pre4, and now after 1 hour
> running haproxy stops accepting new SSL connections. When I restart it
> works again for almost(?) exactly 1 hour, then stops.
> Any idea what might be causing this, or where I should look
>
> # haproxy -vv
> HA-Proxy version 1.8.7 2018/04/07
> Copyright 2000-2018 Willy Tarreau 
>
> Build options :
>   TARGET  = linux2628
>   CPU = generic
>   CC  = gcc
>   CFLAGS  = -O2 -g -fno-strict-aliasing -Wdeclaration-after-statement
> -fwrapv -fno-strict-overflow -Wno-unused-label
>   OPTIONS = USE_LINUX_TPROXY=1 USE_ZLIB=1 USE_REGPARM=1 USE_OPENSSL=1
> USE_PCRE=1
>
> Default settings :
>   maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents = 200
>
> Built with network namespace support.
> Built with zlib version : 1.2.3
> Running on zlib version : 1.2.3
> Compression algorithms supported : identity("identity"),
> deflate("deflate"), raw-deflate("deflate"), gzip("gzip")
> Built with PCRE version : 7.8 2008-09-05
> Running on PCRE version : 7.8 2008-09-05
> PCRE library supports JIT : no (USE_PCRE_JIT not set)
> Built with multi-threading support.
> Encrypted password support via crypt(3): yes
> Built with transparent proxy support using: IP_TRANSPARENT
> IPV6_TRANSPARENT IP_FREEBIND
> Built with OpenSSL version : OpenSSL 1.1.1-pre4 (beta) 3 Apr 2018
> Running on OpenSSL version : OpenSSL 1.1.1-pre4 (beta) 3 Apr 2018
> OpenSSL library supports TLS extensions : yes
> OpenSSL library supports SNI : yes
> OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2 TLSv1.3
>
> Available polling systems :
>   epoll : pref=300,  test result OK
>    poll : pref=200,  test result OK
>  select : pref=150,  test result OK
> Total: 3 (3 usable), will use epoll.
>
> Available filters :
>     [TRACE] trace
>     [COMP] compression
>     [SPOE] spoe
>
> Regards,
> Sander Hoentjen
>