[PATCH] MINOR: systemd: Include MONOTONIC_USEC field in RELOADING=1 message

[Tim Duesterhus]

As per the `sd_notify` manual:

> A field carrying the monotonic timestamp (as per CLOCK_MONOTONIC) formatted
> in decimal in μs, when the notification message was generated by the client.
> This is typically used in combination with "RELOADING=1", to allow the
> service manager to properly synchronize reload cycles. See systemd.service(5)
> for details, specifically "Type=notify-reload".

Thus this change allows users with a recent systemd to switch to
`Type=notify-reload`, should they desire to do so. Correct behavior was
verified with a Fedora 39 VM.

see systemd/systemd#25916
---
 src/haproxy.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/src/haproxy.c b/src/haproxy.c
index 0fcc3e5416..a5f1e79ef9 100644
--- a/src/haproxy.c
+++ b/src/haproxy.c
@@ -844,8 +844,17 @@ void mworker_reload(int hardreload)
}
 
 #if defined(USE_SYSTEMD)
-   if (global.tune.options & GTUNE_USE_SYSTEMD)
-   sd_notify(0, "RELOADING=1\nSTATUS=Reloading Configuration.\n");
+   if (global.tune.options & GTUNE_USE_SYSTEMD) {
+   struct timespec ts;
+
+   (void)clock_gettime(CLOCK_MONOTONIC, );
+
+   sd_notifyf(0,
+  "RELOADING=1\n"
+  "STATUS=Reloading Configuration.\n"
+  "MONOTONIC_USEC=%" PRIu64 "\n",
+  (ts.tv_sec * 100ULL + ts.tv_nsec / 1000ULL));
+   }
 #endif
mworker_reexec(hardreload);
 }
-- 
2.43.2

[PATCH 1/1] CI: extend Fedora Rawhide, add m32 mode

[Ilya Shipitsin]

hopefully it will allow to catch regressions like this
https://github.com/haproxy/haproxy/commit/e41638a
---
 .github/workflows/fedora-rawhide.yml | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/.github/workflows/fedora-rawhide.yml 
b/.github/workflows/fedora-rawhide.yml
index 1bb274557..90f270e5c 100644
--- a/.github/workflows/fedora-rawhide.yml
+++ b/.github/workflows/fedora-rawhide.yml
@@ -11,8 +11,13 @@ jobs:
   build_and_test:
 strategy:
   matrix:
-cc: [ gcc, clang ]
-name: ${{ matrix.cc }}
+platform: [
+  { name: x64, cc: gcc,   QUICTLS_EXTRA_ARGS: "", ADDLIB_ATOMIC: "", 
DEBUG_CFLAGS: "", LDFLAGS: "" },
+  { name: x64, cc: clang, QUICTLS_EXTRA_ARGS: "", ADDLIB_ATOMIC: "", 
DEBUG_CFLAGS: "", LDFLAGS: "" },
+  { name: x86, cc: gcc,   QUICTLS_EXTRA_ARGS: "-m32 linux-generic32", 
ADDLIB_ATOMIC: "-latomic", DEBUG_CFLAGS: "-m32", LDFLAGS: "-m32" },
+  { name: x86, cc: clang, QUICTLS_EXTRA_ARGS: "-m32 linux-generic32", 
ADDLIB_ATOMIC: "-latomic", DEBUG_CFLAGS: "-m32", LDFLAGS: "-m32" }
+]
+name: ${{ matrix.platform.cc }}.${{ matrix.platform.name }}
 runs-on: ubuntu-latest
 if: ${{ github.repository_owner == 'haproxy' }}
 container:
@@ -21,20 +26,21 @@ jobs:
 - uses: actions/checkout@v4
 - name: Install dependencies
   run: |
-dnf -y install git pcre-devel zlib-devel pcre2-devel 'perl(FindBin)' 
perl-IPC-Cmd 'perl(File::Copy)' 'perl(File::Compare)' lua-devel socat findutils 
systemd-devel clang
+dnf -y install diffutils git pcre-devel zlib-devel pcre2-devel 
'perl(FindBin)' perl-IPC-Cmd 'perl(File::Copy)' 'perl(File::Compare)' lua-devel 
socat findutils systemd-devel clang
+dnf -y install 'perl(FindBin)' 'perl(File::Compare)' perl-IPC-Cmd 
'perl(File::Copy)' glibc-devel.i686 lua-devel.i686 lua-devel.x86_64 
systemd-devel.i686 zlib-ng-compat-devel.i686 pcre-devel.i686 libatomic.i686
 - name: Install VTest
   run: scripts/build-vtest.sh
 - name: Install QuicTLS
-  run: QUICTLS=yes scripts/build-ssl.sh
+  run: QUICTLS=yes QUICTLS_EXTRA_ARGS="${{ 
matrix.platform.QUICTLS_EXTRA_ARGS }}" scripts/build-ssl.sh
 - name: Build contrib tools
   run: |
 make admin/halog/halog
 make dev/flags/flags
 make dev/poll/poll
 make dev/hpack/decode dev/hpack/gen-enc dev/hpack/gen-rht
-- name: Compile HAProxy with ${{ matrix.cc }}
+- name: Compile HAProxy with ${{ matrix.platform.cc }}
   run: |
-make -j3 CC=${{ matrix.cc }} V=1 ERR=1 TARGET=linux-glibc 
USE_OPENSSL=1 USE_QUIC=1 USE_ZLIB=1 USE_PCRE=1 USE_PCRE_JIT=1 USE_LUA=1 
USE_SYSTEMD=1 ADDLIB="-Wl,-rpath,${HOME}/opt/lib" SSL_LIB=${HOME}/opt/lib 
SSL_INC=${HOME}/opt/include
+make -j3 CC=${{ matrix.platform.cc }} V=1 ERR=1 TARGET=linux-glibc 
USE_OPENSSL=1 USE_QUIC=1 USE_ZLIB=1 USE_PCRE=1 USE_PCRE_JIT=1 USE_LUA=1 
USE_SYSTEMD=1 ADDLIB="${{ matrix.platform.ADDLIB_ATOMIC }} 
-Wl,-rpath,${HOME}/opt/lib" SSL_LIB=${HOME}/opt/lib SSL_INC=${HOME}/opt/include 
DEBUG_CFLAGS="${{ matrix.platform.DEBUG_CFLAGS }}" LDFLAGS="${{ 
matrix.platform.LDFLAGS }}"
 make install
 - name: Show HAProxy version
   id: show-version
-- 
2.44.0

[PATCH 0/1] CI: extend Fedora Rawhide to run x86 bit as well

[Ilya Shipitsin]

it seems to be the easiest to build "m32" on Fedora comparing to Ubuntu, let's
stick on that for a while

Ilya Shipitsin (1):
  CI: extend Fedora Rawhide, add m32 mode

 .github/workflows/fedora-rawhide.yml | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

-- 
2.44.0

Re: How to check if a domain is known to HAProxy

[Shawn Heisey]

On 4/3/24 06:02, Froehlich, Dominik wrote:
I fear that strict-sni won’t get us far. The issue is that the SNI is 
just fine (it is in the crt-list), however we also need to check if the 
host-header is part of the crt-list. E.g.


William's answer should work.

The strict-sni setting makes sure that the SNI is in the cert list.  If 
it's not, then TLS negotiation will fail and as a result the request 
will not complete.


Then the following ACL in William's reply checks that the host header 
actually matches SNI:


   http-request set-var(txn.host) hdr(host)
   # Check whether the client is attempting domain fronting.
   acl ssl_sni_http_host_match ssl_fc_sni,strcmp(txn.host) eq 0

If SNI matches the Host header, then that ACL will be true.  Combined 
with strict-sni ensuring that the SNI matches one of your certs, this 
will get you what you want.


You can also reverse the ACL so it is false if there is no match.  The 
docs for 2.8 do not mention "ne" as a possible operator, so this ACL 
checks for greater than and less than:


   acl ssl_sni_http_host_no_match ssl_fc_sni,strcmp(txn.host) lt 0
   acl ssl_sni_http_host_no_match ssl_fc_sni,strcmp(txn.host) gt 0

Thanks,
Shawn

Re: How to check if a domain is known to HAProxy

[Froehlich, Dominik]

Hello Willian,

Thank you for your response.

I fear that strict-sni won’t get us far. The issue is that the SNI is just fine 
(it is in the crt-list), however we also need to check if the host-header is 
part of the crt-list. E.g.

curl https://my-host.domain.com -H “host: 
other-host.otherdomain.com”

so here we check for the SNI “my-host.domain.com” automatically via crt-list.

but in the next step we select the backend based on the host-header, but only 
if it also is present in the crt-list (which we use as a list of valid domains 
hosted on the platform)

so based on what you said we can’t do that, we would do something like

http-request set-var(txn.forwarded_host) req.hdr(host),host_only,lower

acl is_known_domain var(txn.forwarded_host),map_dom(/domains.map) -m found

http request-deny if ! is_known_domain

where /domains.map is basically a copy of the crt-list like that:

*.domain.com 1
*.otherdomain.com 1

So, this works, though it is ugly because I need to do double-maintenance of 
the crt-list.
Even if I used strict-sni, you could still run into the issue that SNI is on 
the crt-list, but the host-header is not.



From: William Lallemand 
Date: Wednesday, 3. April 2024 at 11:31
To: Froehlich, Dominik 
Cc: haproxy@formilux.org 
Subject: Re: How to check if a domain is known to HAProxy
On Wed, Apr 03, 2024 at 07:47:44AM +, Froehlich, Dominik wrote:
> Subject: How to check if a domain is known to HAProxy
> Hello everyone,
>
> This may be kind of a peculiar request.
>
> We have the need to block requests that are not in the crt-list of our 
> frontend.
>
> So, the expectation would be that HAProxy does a lookup of the domain (as it 
> does for the crt-list entry) but for domain-fronted requests, i.e. we have to 
> check both the SNI and the host header.
>
> What makes it difficult is that we still want to allow domain-fronting, but 
> only if the host header also matches an entry in the crt-list.
>
> At the moment, I don’t see any way of doing this programmatically, and the 
> crt-list lookup based on the SNI is completely within HAProxy logic.
>
> Is there any way to access the crt-list via an ACL or similar? The 
> alternative would be to maintain the list twice and add it as a map or list 
> to the HAProxy config and then maybe do a custom host matching via LUA script 
> etc. but I really would like to avoid that.
>
> Any hints from the community?
>

Hello,

You can't access the crt-list from the ACL, however if you are using the
`strict-sni` keyword, you will be sure that the requested SNI will be in
your crt-list. And then you can compare the host header with the SNI.

There is an example in the strcmp keyword documentation:

   http-request set-var(txn.host) hdr(host)
   # Check whether the client is attempting domain fronting.
   acl ssl_sni_http_host_match ssl_fc_sni,strcmp(txn.host) eq 0


https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.haproxy.org%2F2.9%2Fconfiguration.html%23strcmp=05%7C02%7Cdominik.froehlich%40sap.com%7Cef9d69783ff54043a83708dc53c0deae%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638477335041142353%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=d8jyQKbe7ODqCI%2BCklprFW9LC67b5yXwHHJYJEQhRGk%3D=0

Regards,

--
William Lallemand

[PATCH] DOC: configuration: grammar fixes for strict-sni

[Nicolas CARPi]

Hello,

Please find attached a little patch for the "strict-sni" configuration 
documentation, which had incorrect grammar.

Best,
~Nicolas
>From 077761ca4b9b3b420ad1f635179cd747dfb7a8eb Mon Sep 17 00:00:00 2001
From: Nicolas CARPi 
Date: Wed, 3 Apr 2024 13:43:59 +0200
Subject: [PATCH] DOC: configuration: grammar fixes for strict-sni

Fix incorrect grammar in strict-sni:
* is allow -> is allowed
* which match -> that matches
* allows to start -> allows starting
---
 doc/configuration.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/configuration.txt b/doc/configuration.txt
index 68af0a844..8ea0c50bd 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -16296,9 +16296,9 @@ ssl-min-ver [ SSLv3 | TLSv1.0 | TLSv1.1 | TLSv1.2 | 
TLSv1.3 ]
 
 strict-sni
   This setting is only available when support for OpenSSL was built in. The
-  SSL/TLS negotiation is allow only if the client provided an SNI which match
+  SSL/TLS negotiation is allowed only if the client provided an SNI that 
matches
   a certificate. The default certificate is not used. This option also allows
-  to start without any certificate on a bind line, so an empty directory could
+  starting without any certificate on a bind line, so an empty directory could
   be used and filled later from the stats socket.
   See the "crt" option for more information. See "add ssl crt-list" command in
   the management guide.
-- 
2.44.0

Re: How to check if a domain is known to HAProxy

[William Lallemand]

On Wed, Apr 03, 2024 at 07:47:44AM +, Froehlich, Dominik wrote:
> Subject: How to check if a domain is known to HAProxy
> Hello everyone,
> 
> This may be kind of a peculiar request.
> 
> We have the need to block requests that are not in the crt-list of our 
> frontend.
> 
> So, the expectation would be that HAProxy does a lookup of the domain (as it 
> does for the crt-list entry) but for domain-fronted requests, i.e. we have to 
> check both the SNI and the host header.
> 
> What makes it difficult is that we still want to allow domain-fronting, but 
> only if the host header also matches an entry in the crt-list.
> 
> At the moment, I don’t see any way of doing this programmatically, and the 
> crt-list lookup based on the SNI is completely within HAProxy logic.
> 
> Is there any way to access the crt-list via an ACL or similar? The 
> alternative would be to maintain the list twice and add it as a map or list 
> to the HAProxy config and then maybe do a custom host matching via LUA script 
> etc. but I really would like to avoid that.
> 
> Any hints from the community?
> 

Hello,

You can't access the crt-list from the ACL, however if you are using the
`strict-sni` keyword, you will be sure that the requested SNI will be in
your crt-list. And then you can compare the host header with the SNI.

There is an example in the strcmp keyword documentation:

   http-request set-var(txn.host) hdr(host)
   # Check whether the client is attempting domain fronting.
   acl ssl_sni_http_host_match ssl_fc_sni,strcmp(txn.host) eq 0


https://docs.haproxy.org/2.9/configuration.html#strcmp

Regards,

-- 
William Lallemand

How to check if a domain is known to HAProxy

[Froehlich, Dominik]

Hello everyone,

This may be kind of a peculiar request.

We have the need to block requests that are not in the crt-list of our frontend.

So, the expectation would be that HAProxy does a lookup of the domain (as it 
does for the crt-list entry) but for domain-fronted requests, i.e. we have to 
check both the SNI and the host header.

What makes it difficult is that we still want to allow domain-fronting, but 
only if the host header also matches an entry in the crt-list.

At the moment, I don’t see any way of doing this programmatically, and the 
crt-list lookup based on the SNI is completely within HAProxy logic.

Is there any way to access the crt-list via an ACL or similar? The alternative 
would be to maintain the list twice and add it as a map or list to the HAProxy 
config and then maybe do a custom host matching via LUA script etc. but I 
really would like to avoid that.

Any hints from the community?