HAProxy 2.0 SSL handshake failure

Help!
24

Means we fixed the issue. This is a different message. I assume there entire heartbeat detection is broken after all the changes since 2014, and this is now a false positive.

Haproxy was build with 1.0.1e and runs with 1.0.1e is what this means. What rpm thinks is installed locally does not really matter, the output shows what actually happens.

Why this is depends on what has been previously done with the system. I also see that zlib and PCRE release don’t match, PCRE is even a different major release. I assume there are some issues with this system, maybe libraries have been upgraded on the system manually, but without taking proper care.

No, this does not seem to be an SSL issue at all. Please open a new thread for this.

25

Means we fixed the issue. I assume there entire heartbeat detection is broken after all the changes since 2014, and this is now a false positive.

Sorry, I didn’t get this. Are you agree there’s an issue with heartbeat detection which should be fixed in haproxy?

Haproxy was build with 1.0.1e and runs with 1.0.1e is what this means.
There’s no openssl 1.0.1e on the machine where haproxy is running.

# ldd /usr/sbin/haproxy | grep libcrypto
        libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007fc0b6338000)
# rpm -qf /lib64/libcrypto.so.10
openssl-1.0.2k-16.150.amzn1.x86_64

Haproxy was built on another machine with CentOS 6 while running on Amazon Linux 1 (1.9.5 was built on the same CentOS host as well). I’m sure the libraries weren’t upgraded or downgraded manually - everything is installed from rpm.

26

I’m saying we have to review this particular behavior.

Check libssl in addition to libcrypto, but I don’t know what Amazon Linux is and I don’t know the detailed inner workings of rpm. The fact of the matter is that the library on your system returns 1.0.1e as version string, but I’m unable to give you any support in that regard.

27

Cool. Thank you!

It looks like Running on OpenSSL version displays the version it was compiled with:

ssl_sock.c:
static void ssl_register_build_options()
{
...
        memprintf(&ptr, "Built with OpenSSL version : "
#ifdef OPENSSL_IS_BORINGSSL
                "BoringSSL");
#else /* OPENSSL_IS_BORINGSSL */
                OPENSSL_VERSION_TEXT
                "\nRunning on OpenSSL version : %s%s",
               OpenSSL_version(OPENSSL_VERSION),
               ((OPENSSL_VERSION_NUMBER ^ OpenSSL_version_num()) >> 8) ? " (VERSIONS DIFFER!)" : "");
#endif

OPENSSL_VERSION is a constant defined in openssl-compat.h:

#define OPENSSL_VERSION         SSLEAY_VERSION

SSLEAY_VERSION seems to be defined in openssl’s crypto.h:
So, haproxy does not seem to be using a runtime openssl version info.

Another proof. I’ve just compiled and run a simple program on the host where haproxy is running:

# cat t.c
#include <openssl/crypto.h>
#include <stdlib.h>
#include <stdio.h>

char *version;

int main() {
  version = SSLeay_version(SSLEAY_VERSION);
  printf("%s\n", version);
}

# ./t
OpenSSL 1.0.2k-fips  26 Jan 2017

# ldd ./t | grep crypto
        libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007fab60575000)

# rpm -qf /lib64/libcrypto.so.10
openssl-1.0.2k-16.150.amzn1.x86_64

Please, try by yourself to build haproxy on a host with one openssl version and run it on a host with another openssl version.

28

I’ll have to take a closer look at this ("running version … " output) also.

However if you build haproxy with openssl 1.0.1, and then run on 1.0.2, no 1.0.2 specific features and code paths will be available, so haproxy will act like you are using 1.0.1.

1 Like