Re: [PATCH] change BoringSSL emulated version back to 1.1.0
On Sun, Oct 18, 2020 at 09:04:51AM +0500, Илья Шипицин wrote: > Hi, > > this is straightforward patch, which is supposed to be backported to all > versions. > master also requires another small patch, will be sent later. > > cheers, > Ilya > From 8cec1c658607a1370bd87682717f5f6512f242d6 Mon Sep 17 00:00:00 2001 > From: Ilya Shipitsin > Date: Sun, 18 Oct 2020 08:55:39 +0500 > Subject: [PATCH] BUILD: ssl: make BoringSSL use its own version numbers > > BoringSSL is a fork of OpenSSL 1.1.0, however in > 49e9f67d8b7cbeb3953b5548ad1009d15947a523 it has changed version to 1.1.1. > > This must be backported to 2.2, 2.1, 2.0, 1.8 > --- > include/haproxy/openssl-compat.h | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/include/haproxy/openssl-compat.h > b/include/haproxy/openssl-compat.h > index acdc9c5bc..d9affa227 100644 > --- a/include/haproxy/openssl-compat.h > +++ b/include/haproxy/openssl-compat.h > @@ -31,6 +31,12 @@ > * extra features with ORs and not with AND NOT. > */ > #define HA_OPENSSL_VERSION_NUMBER 0x1000107fL > +#elif defined(OPENSSL_IS_BORINGSSL) > +/* > + * in 49e9f67d8b7cbeb3953b5548ad1009d15947a523 BoringSSL has changed its > version to 1.1.1 > + * Let's switch it back to 1.1.0 > + */ > +#define HA_OPENSSL_VERSION_NUMBER 0x1010007f > #else /* this is for a real OpenSSL or a truly compatible derivative */ > #define HA_OPENSSL_VERSION_NUMBER OPENSSL_VERSION_NUMBER > #endif Hello, That's interesting to make it build with relatively new versions of boringSSL. But it does not activate TLSv1.3 keywords and features this way. That should probably be enough for backporting in previous versions though. -- William Lallemand
Re: [ANNOUNCE] haproxy-2.3-dev7
Willy, Am 18.10.20 um 17:09 schrieb Willy Tarreau: >> [1] I did not get around fixing the "hiding headers or body at the end >> of the version string is deprecated" one yet. > > I guess this is the one about the health checks ? If so I'm assuming it's > essentially because you're taking care of keeping the config backwards > compatible in case of rollback ? > Yes, exactly. It's not a new warning for me. It already appeared in 2.2 which I was running previously. So its essentially because "Tim is too lazy to read the docs to figure out the new configuration". If it aint broke ..., I guess. I'll get around to it some day. No later than the point where support for putting headers there is removed :-) Best regards Tim Düsterhus
Re: [PATCH] change BoringSSL emulated version back to 1.1.0
пн, 19 окт. 2020 г. в 13:18, William Lallemand : > On Sun, Oct 18, 2020 at 09:04:51AM +0500, Илья Шипицин wrote: > > Hi, > > > > this is straightforward patch, which is supposed to be backported to all > > versions. > > master also requires another small patch, will be sent later. > > > > cheers, > > Ilya > > > From 8cec1c658607a1370bd87682717f5f6512f242d6 Mon Sep 17 00:00:00 2001 > > From: Ilya Shipitsin > > Date: Sun, 18 Oct 2020 08:55:39 +0500 > > Subject: [PATCH] BUILD: ssl: make BoringSSL use its own version numbers > > > > BoringSSL is a fork of OpenSSL 1.1.0, however in > > 49e9f67d8b7cbeb3953b5548ad1009d15947a523 it has changed version to 1.1.1. > > > > This must be backported to 2.2, 2.1, 2.0, 1.8 > > --- > > include/haproxy/openssl-compat.h | 6 ++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/include/haproxy/openssl-compat.h > b/include/haproxy/openssl-compat.h > > index acdc9c5bc..d9affa227 100644 > > --- a/include/haproxy/openssl-compat.h > > +++ b/include/haproxy/openssl-compat.h > > @@ -31,6 +31,12 @@ > > * extra features with ORs and not with AND NOT. > > */ > > #define HA_OPENSSL_VERSION_NUMBER 0x1000107fL > > +#elif defined(OPENSSL_IS_BORINGSSL) > > +/* > > + * in 49e9f67d8b7cbeb3953b5548ad1009d15947a523 BoringSSL has changed > its version to 1.1.1 > > + * Let's switch it back to 1.1.0 > > + */ > > +#define HA_OPENSSL_VERSION_NUMBER 0x1010007f > > #else /* this is for a real OpenSSL or a truly compatible derivative */ > > #define HA_OPENSSL_VERSION_NUMBER OPENSSL_VERSION_NUMBER > > #endif > > Hello, > > That's interesting to make it build with relatively new versions of > boringSSL. But it does not activate TLSv1.3 keywords and features this > way. > > That should probably be enough for backporting in previous versions > though. > yes. in master we can revisit it soon > > -- > William Lallemand >
Re: [PATCH] guard RAND_keep_random_devices_open from BoringSSL
пн, 19 окт. 2020 г. в 16:17, William Lallemand : > On Sat, Oct 17, 2020 at 12:19:09AM +0500, Илья Шипицин wrote: > > while BoringSSL claims to be 1.1.1 compatible, it still misses few > > functions. > > let us add guards (there'll be more in next few days) > > > > cheers, > > Ilya > > > From da98de10e55183319f773032f1518121227396b3 Mon Sep 17 00:00:00 2001 > > From: Ilya Shipitsin > > Date: Sat, 17 Oct 2020 00:07:53 +0500 > > Subject: [PATCH] BUG/MINOR: do not call RAND_keep_random_devices_open if > > BoringSSL used > > > > there's no such function defined in BoringSSL. > > this must be backported to 2.2, 2.1, 2.0, 1.8 > > --- > > src/haproxy.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/src/haproxy.c b/src/haproxy.c > > index 83e57ce6e..392f92467 100644 > > --- a/src/haproxy.c > > +++ b/src/haproxy.c > > @@ -780,7 +780,7 @@ void mworker_reload() > > if (fdtab) > > deinit_pollers(); > > } > > -#if defined(USE_OPENSSL) && (HA_OPENSSL_VERSION_NUMBER >= 0x10101000L) > > +#if defined(USE_OPENSSL) && (HA_OPENSSL_VERSION_NUMBER >= 0x10101000L > && !defined OPENSSL_IS_BORINGSSL) > > /* close random device FDs */ > > RAND_keep_random_devices_open(0); > > #endif > > -- > > 2.26.2 > > > > This one should be dropped? > yes. > > -- > William Lallemand >
Re: [PATCH] guard RAND_keep_random_devices_open from BoringSSL
On Sat, Oct 17, 2020 at 12:19:09AM +0500, Илья Шипицин wrote: > while BoringSSL claims to be 1.1.1 compatible, it still misses few > functions. > let us add guards (there'll be more in next few days) > > cheers, > Ilya > From da98de10e55183319f773032f1518121227396b3 Mon Sep 17 00:00:00 2001 > From: Ilya Shipitsin > Date: Sat, 17 Oct 2020 00:07:53 +0500 > Subject: [PATCH] BUG/MINOR: do not call RAND_keep_random_devices_open if > BoringSSL used > > there's no such function defined in BoringSSL. > this must be backported to 2.2, 2.1, 2.0, 1.8 > --- > src/haproxy.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/src/haproxy.c b/src/haproxy.c > index 83e57ce6e..392f92467 100644 > --- a/src/haproxy.c > +++ b/src/haproxy.c > @@ -780,7 +780,7 @@ void mworker_reload() > if (fdtab) > deinit_pollers(); > } > -#if defined(USE_OPENSSL) && (HA_OPENSSL_VERSION_NUMBER >= 0x10101000L) > +#if defined(USE_OPENSSL) && (HA_OPENSSL_VERSION_NUMBER >= 0x10101000L && > !defined OPENSSL_IS_BORINGSSL) > /* close random device FDs */ > RAND_keep_random_devices_open(0); > #endif > -- > 2.26.2 > This one should be dropped? -- William Lallemand
Re: Crash when using wlc in multithreaded mode with agent checks (1.8.26).
Le 16/10/2020 à 10:04, Christopher Faulet a écrit : Le 13/10/2020 à 14:53, Peter Statham a écrit : Hello, We've found an issue when using agent checks in conjunction with the weighted least connections algorithm in multithreaded mode. It seems to me as if it is possible for next_eweight in struct server to be modified in another thread during the execution of fwlc_srv_reposition. If next_eweight is set to zero then a division by zero occurs on line 59 in src/lb_fwlc.c in fwlc_queue_srv. I notice that in haproxy-2.0.18 this section of code is protected by HA_SPINLOCKs and I've been unable to replicate this issue in that version. I've written an agent (attached), bad_agent.py, which provokes this condition by switching randomly between 1 and 0 percent. I also include a minimal configuration, cfg (also attached), which seems sufficient to cause the issue. With these two running “ab -n 500 -c 500 http://192.168.92.1:8080/” will quickly crash the haproxy process. I include links to a coredump and the binary that generated it (unstripped). The backtrace of thread 1 follows. Hi, Thanks for the reproducer. I'm able to crash HAProxy too using your config and your agent. It seems to only crash on the 1.8. I'll investigate. Hi, In fact, it fails in all branches supporting the threads. The leasconn and first loadbalancing algorithms are affected by this bug. In leastconn, it may crash because of the division by 0 when the server weight is set to 0. But for the both algos, the server tree may be also corrupted, leading to stranger and undefined bugs. I pushed a fix (commit 26a52a) and backported it as far as 1.8. So, it should be fixed in all branches now. Thanks ! -- Christopher Faulet
Re: [PATCH] change BoringSSL emulated version back to 1.1.0
I've just tested, this patch is required for 2.1 as well (it was applied today for 2.2 and master) вс, 18 окт. 2020 г. в 09:14, Илья Шипицин : > this is only for master > > вс, 18 окт. 2020 г. в 09:04, Илья Шипицин : > >> Hi, >> >> this is straightforward patch, which is supposed to be backported to all >> versions. >> master also requires another small patch, will be sent later. >> >> cheers, >> Ilya >> >
IP binding and standby health-checks
Hello, I'm new to this list and somewhat new to HAProxy. Before posting I scanned the archives and found a thread from 2015 that seems to apply to my situation: IP binding and standby health-checks https://www.mail-archive.com/haproxy@formilux.org/msg18728.html The specifics of our setup: * HAProxy Active/Standby pair using keepalived and a virtual IP. * Load balance SSH connections to a group of user access systems (long-running Layer 4 connections). * Using Fail2Ban to protect against password attacks, so using send-proxy-v2 and go-mmproxy to present client IP to target servers. Our objective is to preserve connections through a fail-over. It would seem that it is necessary to use the virtual IP as the source address for connections to the target servers. The problem, though, is how get get HAProxy not to use the virtual IP for health checks. Since the HAProxy code-base has likely evolved since 2015 I'd like to know the current recommended approach for this situation. Thanks. -Dave -- Dave Hall Binghamton University
