Hello,
On 23 May 2018 at 18:29, Emeric Brun <eb...@haproxy.com> 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
