Re: Update for https://github.com/haproxy/wiki/wiki/SPOE:-Stream-Processing-Offloading-Engine
On Mon, Apr 15, 2024 at 10:18:19AM +0200, Aleksandar Lazic wrote: > Hi. > > The "https://github.com/criteo/haproxy-spoe-go; is archived since Nov 7, > 2023 and there is a fork from that repo https://github.com/go-spop/spoe > Can we add this info to the wiki page? > > There is also a rust implementation > https://github.com/vkill/haproxy-spoa-example which could be added. > > If it's possible then would I add this by my self. > Thanks Aleks, I add them both on the page, and set criteo's one as unmaintained. -- William Lallemand
Re: [PATCH 1/2] CI: reduce ASAN log redirection umbrella size
On Sun, Apr 14, 2024 at 09:23:51AM +0200, Ilya Shipitsin wrote:
> previously ASAN_OPTIONS=log_path=asan.log was intended for VTest
> execution only, it should not affect "haproxy -vv" and hsproxy
> config smoke testing
> ---
> .github/workflows/vtest.yml | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/.github/workflows/vtest.yml b/.github/workflows/vtest.yml
> index 9d0bf48b0..5ee8a7a64 100644
> --- a/.github/workflows/vtest.yml
> +++ b/.github/workflows/vtest.yml
> @@ -42,8 +42,6 @@ jobs:
># Configure a short TMPDIR to prevent failures due to long unix socket
># paths.
>TMPDIR: /tmp
> - # Force ASAN output into asan.log to make the output more readable.
> - ASAN_OPTIONS: log_path=asan.log
>OT_CPP_VERSION: 1.6.0
> steps:
> - uses: actions/checkout@v4
> @@ -143,6 +141,9 @@ jobs:
>run: echo "::add-matcher::.github/vtest.json"
> - name: Run VTest for HAProxy ${{ steps.show-version.outputs.version }}
>id: vtest
> + env:
> +# Force ASAN output into asan.log to make the output more readable.
> +ASAN_OPTIONS: log_path=asan.log
>run: |
> # This is required for macOS which does not actually allow to
> increase
> # the '-n' soft limit to the hard limit, thus failing to run.
Ilya,
I still don't get how ASAN is working with the CI. Each time I have an
ASAN issue I can't get a trace out of github.
For example, there was an issue with ASAN in this commit:
https://github.com/haproxy/haproxy/commit/bdee8ace814139771efa90cc200c67e7d9b72751
I couldn't get a trace in the CI:
https://github.com/haproxy/haproxy/actions/runs/8724600484/job/23936238899
But I had no problem when testing it from my computer, I'm just doing a
` make reg-tests reg-tests/ssl/crt_store.vtc -- --debug` and have the
ASAN output directly.
Do you think we could achieve the same thing with github actions? I
never saw an output from this asan.log file in the CI.
--
William Lallemand
Re: Changes in HAProxy 3.0's Makefile and build options
On Thu, Apr 11, 2024 at 11:43:14PM +0200, Dinko Korunic wrote: > Subject: Re: Changes in HAProxy 3.0's Makefile and build options > > > On 11.04.2024., at 21:32, William Lallemand wrote: > > > > If I remember correctly github actions VMs only had 2 vCPU in the past, > > I think they upgraded to 4 vCPU last year but I can't find anything in > > their documentation. > > Hi William, > > GitHub runners Instance sizes for public repositories are now as you said, 4 > vCPU / 16 GB RAM: > > https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners/about-github-hosted-runners > > > Kind regards, > D. > Indeed, thanks for confirming! I didn't know there was a difference with private repositories which are still using 2 vCPU, that explains a lot. -- William Lallemand
Re: Changes in HAProxy 3.0's Makefile and build options
On Thu, Apr 11, 2024 at 09:04:51PM +0200, Willy Tarreau wrote: > Subject: Re: Changes in HAProxy 3.0's Makefile and build options > Hi Ilya, > > On Thu, Apr 11, 2024 at 08:27:39PM +0200, ??? wrote: > > do you know maybe how this was supposed to work ? > > haproxy/Makefile at master · haproxy/haproxy (github.com) > > <https://github.com/haproxy/haproxy/blob/master/Makefile#L499> > > That's this: > > ifneq ($(shell $(CC) $(CFLAGS) -dM -E -xc - /dev/null | grep > -c 'LOCK_FREE.*1'),0) > USE_LIBATOMIC = implicit > endif > > It calls the compiler with the known flags and checks if for this arch, > it's configured to require libatomic. > > > I had to enable atomic explicitly despite it was supposed to be detected on > > the fly (I haven't had a deeper look yet) > > > > haproxy/.github/workflows/fedora-rawhide.yml at master · haproxy/haproxy > > <https://github.com/haproxy/haproxy/blob/master/.github/workflows/fedora-rawhide.yml#L17-L18> > > I honestly don't know why it's not working, it could be useful to achive > the output of this command, either by calling it directly or for example > by inserting "tee /tmp/log |" before grep. If you have a copy of the linker > erorr you got without the lib, maybe it will reveal something. But honestly > this is a perfect example of the reasons why I prefer generic makefiles to > automatic detection: you see that you need libatomic, you add it, done. No > need to patch a configure to mask an error due to an unhandled special case > etc. The test above was mostly meant to ease the build for the most common > cases (and for me till now it has always worked, on various systems and > hardware), but I wouldn't mind too much. > > In fact you could simplify your build script by just passing > USE_LIBATOMIC=1 to enable it. > > BTW, is there a reason for "make -j3" in the build script ? Limiting oneself > to 3 build processes when modern machines rarely have less than 8 cores is > a bit of a waste of time, especially if every other package does the same > in the distro! I'd just do "make -j$(nproc)" as usual there. > If I remember correctly github actions VMs only had 2 vCPU in the past, I think they upgraded to 4 vCPU last year but I can't find anything in their documentation. -- William Lallemand
Re: [PATCH] MINOR: systemd: Include MONOTONIC_USEC field in RELOADING=1 message
On Thu, Apr 04, 2024 at 04:00:16PM +0200, Tim Düsterhus wrote: > Hi > > On 4/4/24 14:35, William Lallemand wrote: > > I'm not against merging this, but I don't see any change comparing to the > > current model? > > > > I mainly stumbled upon this new mode in the documentation while looking into > replacing libsystemd, where you beat me to it :-) > > My understanding is that it improves the situation insofar that systemd > knows that the reload (attempt) is not yet finished even if the kill command > exits. > > Currently it's the following: > > - systemd executes the kill. > - kill exists. > - systemd believes the reload finished. > - HAProxy sees the signal, sends RELOADING=1. > - systemd believes a second reload started. > - HAProxy finishes reloading, sends READY=1. > - systemd believes the second reload finished. > With the new mode it's: > > - systemd sends the signal. > - systemd waits for RELOADING=1. > - HAProxy sees the signal, sends RELOADING=1. > - HAProxy finishes reloading, sends READY=1. > - systemd believes the reload finished. > > The new mode is only available with very recent systemd versions, but we can > future-proof the implementation by already including the MONOTONIC_USEC > field in the message. Unknown fields are explicitly ignored by systemd, thus > this patch makes the situation no worse. I thought systemd was already waiting the READY=1 message in fact, I made a few tests which confirms your explanation, thanks, merged! What I find stupid is that it's not possible to have the red "systemd[1]: Reload failed for haproxy.service" message when using all these reload method... For example if you replace `kill`by `false` in the unit file, you will have: wla@kikyo:~% systemctl status haproxy ● haproxy.service - HAProxy Load Balancer Loaded: loaded (/etc/systemd/system/haproxy.service; enabled; preset: enabled) Active: active (running) since Thu 2024-04-04 15:04:20 CEST; 1h 4min ago Docs: man:haproxy(1) file:/usr/share/doc/haproxy/configuration.txt.gz Process: 58596 ExecReload=/usr/bin/false (code=exited, status=1/FAILURE) Main PID: 57180 (haproxy) Status: "Ready." Tasks: 9 (limit: 18702) Memory: 74.6M CPU: 1.624s CGroup: /system.slice/haproxy.service ├─57180 /usr/sbin/haproxy -Ws -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -S /run/haproxy-master.sock └─57601 /usr/sbin/haproxy -sf 57557 -x sockpair@5 -Ws -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -S /run/haproxy-master.sock Apr 04 15:14:12 kikyo systemd[1]: Reload failed for haproxy.service - HAProxy Load Balancer. Apr 04 15:14:33 kikyo systemd[1]: Reloading haproxy.service - HAProxy Load Balancer... Apr 04 15:14:33 kikyo systemd[1]: haproxy.service: Control process exited, code=exited, status=1/FAILURE Apr 04 15:14:33 kikyo systemd[1]: Reload failed for haproxy.service - HAProxy Load Balancer. Apr 04 15:14:48 kikyo systemd[1]: Reloading haproxy.service - HAProxy Load Balancer... Apr 04 15:14:48 kikyo systemd[1]: haproxy.service: Control process exited, code=exited, status=1/FAILURE Apr 04 15:14:48 kikyo systemd[1]: Reload failed for haproxy.service - HAProxy Load Balancer. Apr 04 15:17:20 kikyo systemd[1]: Reloading haproxy.service - HAProxy Load Balancer... Apr 04 15:17:20 kikyo systemd[1]: haproxy.service: Control process exited, code=exited, status=1/FAILURE Apr 04 15:17:20 kikyo systemd[1]: Reload failed for haproxy.service - HAProxy Load Balancer. With messages hilighted in red, and a clear failure of the reload on the "Process" line. I can't find a way of achieving the same thing with sd_notify() :( -- William Lallemand
Re: [PATCH] MINOR: systemd: Include MONOTONIC_USEC field in RELOADING=1 message
On Wed, Apr 03, 2024 at 10:39:16PM +0200, Tim Duesterhus wrote:
> 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);
> }
It looks like they still failed to implement a correct reload status
with this mode. Honestly I don't get it, to me it does not improve
anything :/
Given that the only signal we can send is READY=1 and that only a
failure of a ExecReload= command would set a reloading error, it does
exactly the same as the current kill -USR2 method.
I think only implementing a synchronous `haproxyctl reload` command
which uses the master CLI could improve the situation, only that could
return a failure and emits the error output...
I'm not against merging this, but I don't see any change comparing to the
current model?
--
William Lallemand
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://docs.haproxy.org/2.9/configuration.html#strcmp Regards, -- William Lallemand
Re: RFC: PKCS#11 create private keys in worker process
On Thu, Mar 28, 2024 at 08:26:58AM +0800, Richard Chan wrote: > Hello, > > This is an RFC to recreate private keys in the worker process > for PKCS#11, so that HSM keys can be used in -W mode. > > - ssl_ckch.c: add map of ckch_data to PEM data > - ssl_sock.c: add map of SSL_CTX* to ckch_data > - maps are implemented using buckets of linked lists > it is explicit and in the code for easier review instead of using > more optimized hashmap implementations > - when the SSL context is created and the correct SSL_CTX is assigned > with SSL_use_SSL_CTX > the private key data is retrieved just once once, cached, and installed > into the > SSL_CTX; > this is done in the worker process > - the PEM data has an arbitrary limit of 16384 bytes > Hello Richard, I'd rather not add another cache on top of the current cache system, it will complexify the loading and we are trying to simplify it. Did you identify why the fork was causing an issue? We should probably try to understand this before, it could be something stupid in haproxy's code or in the pkcs11 provider. For 3.1 I plan to move the configuration loading in the worker so you won't have this problem anymore. We still need to validate that everything will be compatible but I have good hope that it's doable and will cleanup a lot of startup code. There is an experimental branch there https://github.com/haproxy/haproxy/commits/20240131-mworkerv3-rewrite/ It does not do much for now but it could be enough to test the startup with an HSM. I'll try to test this when I have some time. Regards, -- William Lallemand
Re: [PR] FEATURE: load private keys from PKCS#11 pkcs11-provider PEM files
On Thu, Mar 21, 2024 at 05:34:12PM +0800, Richard Chan wrote: > Yes I would be happy to include HAProxy with pkcs11-provider examples. > Great, thank you! I made a `PKCS11 provider` https://github.com/haproxy/wiki/wiki/OpenSSL-Providers-in-HAProxy#pkcs11-provider that you could edit once we give you the rights. Willy: Could you give the right to edit this page to the `space88man` github user? Thanks! -- William Lallemand
Re: [PR] FEATURE: load private keys from PKCS#11 pkcs11-provider PEM files
On Thu, Mar 21, 2024 at 10:39:58AM +0800, Richard Chan wrote: > Subject: Re: [PR] FEATURE: load private keys from PKCS#11 pkcs11-provider PEM > files > On Thu, 21 Mar 2024, 00:15 William Lallemand, wrote > > > > > We made test in the past with the TPM2 provider which also uses a URI in > > the privatekey: > > > > https://github.com/haproxy/wiki/wiki/OpenSSL-Providers-in-HAProxy#tpm2-provider > > > Further testing shows that this PR is not needed. Sorry for the noise. > > There is a glitch in pkcs11-provider that requires the private key to be > the first PEM object. Apart from this HAProxy loads the private key with > no issues. > Okay that's good to read :-) Would you be interested in contributing on the OpenSSL providers wiki page? We could have a pkcs11 section like the one we already have for the TPM2 provider. Regards, -- William Lallemand
Re: [PR] FEATURE: load private keys from PKCS#11 pkcs11-provider PEM files
On Wed, Mar 20, 2024 at 05:15:47PM +0100, William Lallemand wrote: > >TODO: This PR works > >without forking (i.e., not in master-worker mode) as PKCS#11 drivers > >are fragile after fork. > >To use PKCS#11 keys in master-worker mode, > >we need to defer key loading to the child process. > > Also, regarding this part, I must look what the exact problem is with the pkcs11. But we have in mind a rearchitecture of the master-worker which could simplify this kind of problem. But that won't be before HAProxy 3.1 unfortunately :-) -- William Lallemand
Re: [PR] FEATURE: load private keys from PKCS#11 pkcs11-provider PEM files
On Wed, Mar 20, 2024 at 06:23:03AM +, PR Bot wrote: > Subject: [PR] FEATURE: load private keys from PKCS#11 pkcs11-provider PEM > files > Dear list! > > Author: S-P Chan > Number of patches: 1 > > This is an automated relay of the Github pull request: >FEATURE: load private keys from PKCS#11 pkcs11-provider PEM files > > Patch title(s): >FEATURE: load private keys from PKCS#11 pkcs11-provider PEM files > > Link: >https://github.com/haproxy/haproxy/pull/2493 > > Edit locally: >wget https://github.com/haproxy/haproxy/pull/2493.patch && vi 2493.patch > > Apply locally: >curl https://github.com/haproxy/haproxy/pull/2493.patch | git am - > > Description: >With pkcs11-provider (https://github.com/latchset/pkcs11-provider) a >specially formatted PEM stanza can be used >to reference a PKCS#11 >URI to locate the private key. > >This PEM stanza can be used >inside the crt file so that there is no change to the HAProxy config >language. > >This works with OpenSSL 3 and pkcs11-provider after >https://github.com/latchset/pkcs11-provider/commit/0806c3665 which >added support for PKCS#11 URI-in-PEM. > >TODO: This PR works >without forking (i.e., not in master-worker mode) as PKCS#11 drivers >are fragile after fork. >To use PKCS#11 keys in master-worker mode, >we need to defer key loading to the child process. > >Format of >PEM stanza: >``` >-BEGIN PKCS#11 PROVIDER URI- >MIHWGhlQS0NTIzExIFByb3ZpZGVyIFVSSSB2MS4wDIG4cGtjczExOm1vZGVsPU5T >UyUyMDM7bWFudWZhY3R1cmVyPU1vemlsbGElMjBGb3VuZGF0aW9uO3NlcmlhbD0w >MDAwMDAwMDAwMDAwMDAwO3Rva2VuPU5TUyUyMENlcnRpZmljYXRlJTIwREI7aWQ9 >JTczJTQ5JTU1JTFBJTMyJUFFJThDJUIwJTQ1JTQ5JTAzJURDJUE4JTA0JTg0JTlF >JUI0JTlGJTQxJUFFO3R5cGU9cHJpdmF0ZQ== >-END PKCS#11 PROVIDER >URI- >``` > >Parsed ASN.1: >``` >0:d=0 hl=3 l= >214 cons: SEQUENCE >3:d=1 hl=2 l= 25 prim: VISIBLESTRING >:PKCS#11 Provider URI v1.0 > 30:d=1 hl=3 l= 184 prim: UTF8STRING >:pkcs11:model=NSS%203;manufacturer=Mozilla%20Foundation;serial=000 >0;token=NSS%20Certificate%20DB;id=%73%49%55%1A%32%AE%8C%B0%45% >49%03%DC%A8%04%84%9E%B4%9F%41%AE;type=private >``` > > Instructions: >This github pull request will be closed automatically; patch should be >reviewed on the haproxy mailing list (haproxy@formilux.org). Everyone is >invited to comment, even the patch's author. Please keep the author and >list CCed in replies. Please note that in absence of any response this >pull request will be lost. > Hello, Thank you for your contribution, I'm surprised this is not already working with the current code. We made test in the past with the TPM2 provider which also uses a URI in the privatekey: https://github.com/haproxy/wiki/wiki/OpenSSL-Providers-in-HAProxy#tpm2-provider Do you have any specific configuration for HAProxy? Regards, -- William Lallemand
Re: Dataplane exits at haproxytech/haproxy-ubuntu:2.9 in Containers
On Sun, Mar 17, 2024 at 07:53:17PM +0100, Aleksandar Lazic wrote: > Hi. > > Looks like there was a similar question in the forum > https://discourse.haproxy.org/t/trouble-with-starting-the-data-plane-api/9200 > > Any idea how to fix this? > Honestly no idea, you should try an issue there: https://github.com/haproxytech/dataplaneapi/issues -- William Lallemand
[ANNOUNCE] haproxy-2.8.7
Hi, HAProxy 2.8.7 was released on 2024/02/26. It added 1 new commits after version 2.8.6. This version was emitted shortly after the 2.8.6 in order to fix a recent regression. Indeed, people using the OCSP feature with manual CLI update (set ssl ocsp-response) have reported crashes. The crashes were introduced in an attempt to fix a problem with the ocsp-update feature combined with the 'set ssl cert' CLI command. The former problem could still happen and we are still investigating a better way to fix it. The patches were reverted in order to fix the historical OCSP feature, and avoid crashes during soft-stop. People that are using the OCSP and the 2.8.6 release are encouraged to update to this version. Please find the usual URLs below : Site index : https://www.haproxy.org/ Documentation: https://docs.haproxy.org/ Wiki : https://github.com/haproxy/wiki/wiki Discourse: https://discourse.haproxy.org/ Slack channel: https://slack.haproxy.org/ Issue tracker: https://github.com/haproxy/haproxy/issues Sources : https://www.haproxy.org/download/2.8/src/ Git repository : https://git.haproxy.org/git/haproxy-2.8.git/ Git Web browsing : https://git.haproxy.org/?p=haproxy-2.8.git Changelog: https://www.haproxy.org/download/2.8/src/CHANGELOG Dataplane API: https://github.com/haproxytech/dataplaneapi/releases/latest Pending bugs : https://www.haproxy.org/l/pending-bugs Reviewed bugs: https://www.haproxy.org/l/reviewed-bugs Code reports : https://www.haproxy.org/l/code-reports Latest builds: https://www.haproxy.org/l/dev-packages --- Complete changelog : William Lallemand (1): BUG/MAJOR: ssl/ocsp: crash with ocsp when old process exit or using ocsp CLI --- -- William Lallemand
[ANNOUNCE] haproxy-2.9.6
Hi, HAProxy 2.9.6 was released on 2024/02/26. It added 2 new commits after version 2.9.5. This version was emitted shortly after the 2.9.5 in order to fix a recent regression. Indeed, people using the OCSP feature with manual CLI update (set ssl ocsp-response) have reported crashes. The crashes were introduced in an attempt to fix a problem with the ocsp-update feature combined with the 'set ssl cert' CLI command. The former problem could still happen and we are still investigating a better way to fix it. The patches were reverted in order to fix the historical OCSP feature, and avoid crashes during soft-stop. This version also fixes a crash that could happen when using the 'del server' CLI command combined with the prometheus exporter. People that are using the OCSP and the 2.9.5 release are encouraged to update to this version. Please find the usual URLs below : Site index : https://www.haproxy.org/ Documentation: https://docs.haproxy.org/ Wiki : https://github.com/haproxy/wiki/wiki Discourse: https://discourse.haproxy.org/ Slack channel: https://slack.haproxy.org/ Issue tracker: https://github.com/haproxy/haproxy/issues Sources : https://www.haproxy.org/download/2.9/src/ Git repository : https://git.haproxy.org/git/haproxy-2.9.git/ Git Web browsing : https://git.haproxy.org/?p=haproxy-2.9.git Changelog: https://www.haproxy.org/download/2.9/src/CHANGELOG Dataplane API: https://github.com/haproxytech/dataplaneapi/releases/latest Pending bugs : https://www.haproxy.org/l/pending-bugs Reviewed bugs: https://www.haproxy.org/l/reviewed-bugs Code reports : https://www.haproxy.org/l/code-reports Latest builds: https://www.haproxy.org/l/dev-packages --- Complete changelog : Amaury Denoyelle (1): BUG/MAJOR: promex: fix crash on deleted server William Lallemand (1): BUG/MAJOR: ssl/ocsp: crash with ocsp when old process exit or using ocsp CLI --- -- William Lallemand
Re: WolfSSL builds for use with HAProxy
On Fri, Feb 09, 2024 at 11:00:24PM +, Tristan wrote: > Hi Ilya, > > On 09/02/2024 20:31, Илья Шипицин wrote: > > I run QUIC Interop from time to time, WolfSSL shows the best > > compatibility compared to LibreSSL and aws-lc. > > it really looks like a winner today > > And in comparison to current QuicTLS? > > > I'm afraid it practice it works in a different way. > > First, you install WolfSSL to prod, next INSTALL/wiki got updated :) > > I appreciate the joke... :) Well, unfortunately they are a lot of unknows with wolfSSL, so we every new user could discover them :-) > > Either way, for now I'm waiting on OCSP support first (hi William, Rémi); > hopefully someone else figures out the best build flags by the time that's > dealt with. I'll add that to my list but that's not the biggest priority for now :) -- William Lallemand
Re: WolfSSL builds for use with HAProxy
On Thu, Feb 08, 2024 at 02:46:46PM +, Tristan wrote: > Hi all, > Hello, > With the ever-increasing threat of one day needing to give up on OpenSSL > 1.1.1 (whenever the next bad CVE is found on QuicTLS 1.1.1w, essentially) I > was looking at alternatives a bit closer. > > Based on the wiki, > https://github.com/openssl/openssl/issues/20286#issuecomment-1527869072, and > that it has support for other features I'm interested in (notably ECH), > WolfSSL seems by far my best bet at the moment. > I have personnally more hope with aws-lc, given the fact that this is a fork of a stack we know, and they maintain a stable ABI. But we don't even have the clienthello callback in it yet, we have to invest some time on this library too. But WolfSSL could a good alternative for you, but this is still experimental. > However, given that almost everything is compile time and defaults focus on > suitability for constrained embedded environments rather than best > big-proxy-server oriented performance, does anyone have pointers on what > flags are important/traps/etc? > > Besides the getrandom thing, HAProxy's INSTALL/wiki only vaguely mention > that such build-time tuning is required, so I'm hoping someone might have > gone through that already. > --enable-haproxy is suppose to enable every features we support. you could be needing --enable-keylog-export for debugging with the keylog file, but it actually does not support TLS1.3 so that would be useless for QUIC. You also need --enable-quic. The other useful flags are optimizations depending on your CPU, for example --enable-aesni , --enable-intelasm . > This one is a bit extra, but considering that aiming for bleeding edge with > WolfSSL is not entirely compatible with how most distros work (ie even if it > was packaged, it's likely going to be perpetually quite far behind), what > does the future look like in that regard from the distros' side? > 5.6.6 is already in debian testing and will be in the next ubuntu LTS release, the problem is that it won't be compatible with haproxy... We are trying to make them enable the haproxy features in --enable-distro but it seems like it's already too late. At least --enable-quic is now enable by default. https://github.com/wolfSSL/wolfssl/issues/6834 So basically we reached a deadlock which will last 2 years. Regarding Redhat I don't think they are even packaging it. But yes, wolfssl cycles are not really compatible with LTS distro, so it would need a PPA which provides the updated lib with the right flags. -- William Lallemand
Re: [PATCH] DOC: install: clarify WolfSSL chroot requirements
On Fri, Feb 02, 2024 at 05:33:08PM +, Lukas Tribus wrote: > Subject: [PATCH] DOC: install: clarify WolfSSL chroot requirements > --- > INSTALL | 12 > 1 file changed, 12 insertions(+) > > diff --git a/INSTALL b/INSTALL > index 18eb67f311..8ebf8d298c 100644 > --- a/INSTALL > +++ b/INSTALL > @@ -293,6 +293,18 @@ Please also note that wolfSSL supports many > platform-specific features that may > affect performance, and that for production uses it might be a good idea to > check them using "./configure --help". Please refer to the lib's > documentation. > > +When running wolfSSL in chroot, either mount /dev/[u]random devices into the > +chroot: > + > + $ mkdir -p /path/to/chrootdir/dev/ > + $ mknod -m 444 /path/to/chrootdir/dev/random c 1 8 > + $ mknod -m 444 /path/to/chrootdir/dev/urandom c 1 9 > + > +Or, if your OS supports it, enable the getrandom() syscall by appending the > +following argument to the wolfSSL configure command: > + > + EXTRA_CFLAGS=-DWOLFSSL_GETRANDOM=1 > + > Building HAProxy with wolfSSL requires to specify the API variant on the > "make" > command line, for example: > > -- > 2.17.1 > Merged, thanks! I also made some tests with RAND_bytes() after chroot() which seems to work so it's kind of difficult to understand what's going on. HAProxy doesn't seem to try opening /dev/urandom once it chroot'ed, and the clients are getting SIGPIPEs. So, I believe some initialization are failing in HAProxy and we are not checking it correctly. It might be interesting to dig that a little bit. -- William Lallemand
Re: [PATCH 0/2] CI cleanup and improvement
On Fri, Feb 02, 2024 at 08:33:14PM +0100, Ilya Shipitsin wrote: > Subject: [PATCH 0/2] CI cleanup and improvement > remove redundant function, improve openssl download helper > > Ilya Shipitsin (2): > CI: cleanup: abandon asan matrix.py helper > BUILD: SSL: add yet another OpenSSL download fallback > > .github/matrix.py| 15 +-- > scripts/build-ssl.sh | 4 +++- > 2 files changed, 8 insertions(+), 11 deletions(-) > > -- > 2.43.0 > > Thanks, merged! -- William Lallemand
Re: [PATCH] DOC: install: enable WOLFSSL_GETRANDOM
On 2024-02-02 16:38, Lukas Tribus wrote: WolfSSL support in HAProxy is experimental to the point that not only does it require compiling library and application from source, it also requires tinkering with LD paths to be able to even start the binary, so it's not like the INSTALL instructions are "ready to roll" in production. I'll fix this, I thought I put the same command line that I'm using in my script, but it lacks ADDLIB=-Wl,-rpath=/opt/wolfssl/lib/. -- William Lallemand
Re: [PATCH] DOC: install: enable WOLFSSL_GETRANDOM
On 2024-02-01 15:52, Lukas Tribus wrote: On Thu, 1 Feb 2024 at 12:08, William Lallemand wrote: > > That's interesting, however I'm surprised the init does not work before the chroot, > we are doing a RAND_bytes() with OpenSSL before the chroot to achieve this. This approach can actually hide chroot issues leading to nasty operational issues like "Haproxy 1.8 with OpenSSL 1.1.1-pre4 stops working after 1 hour" (see [1] and [2]). It's also not unrealistic to cause issue with process management, like FD leaks [3]. Sure, these were fixable bugs due to changes in HAProxy or in OpenSSL. But once a FD is kept and the library deinit correctly that shouldn't be a major problem.I agree we should be attentive to these points. Stable OpenSSL on stable OS release branches today use getrandom() and not /dev/urandom. I think using the filesystems for CRNG is a footgun. At least let us fail fast and immediately if there is an issue with CRNG seeding from chroot. I consider getrandom() a modern and simple solution to all those problems. Unfortunately this is still a fallback solution if getrandom() is not accessible or if the support is not built, as this is a fallback in openssl too.I don't want HAProxy to require getrandom() to work, even if this is not an ideal solution, there is no reason it shouldn't work without it, at least for the sake of portability. > I'll check if we can do something like this instead of needing a explicit option, but > if that's not possible we will require GETRANDOM in the --enable-haproxy build option. Actually I think wolfssl should add feature detection just like it does with other optional syscalls. But that is not what the suggested wolfssl 5.6.6 release does. It does not seem to be the wolfSSL philosophy :/ Everything needs to be compiled manually and there is a lot of options, it's quite complicated to obtain an optimized built... We recently saw that they've done something like this for AES-NI, so maybe we could try to push them to a more dynamic build system. I opened a wolfSSL issue https://github.com/wolfSSL/wolfssl/issues/7197 feel free to participate, we could try to push them to the detection of getrandom() during the build of their library, and fix their urandom Implementation. We could also try a call to RAND_bytes() after the chroot and exit with an error saying that the library is not compatible with chroot. Regards, William Lallemand
Re: [PATCH] DOC: install: enable WOLFSSL_GETRANDOM
On 2024-01-30 20:45, Lukas Tribus wrote: Suggest enabling getrandom() syscall in wolfssl to avoid chroot problems when using wolfssl. --- Also see: https://discourse.haproxy.org/t/haproxy-no-responses-when-built-with-wolfssl-while-working-with-openssl/9320/15 --- INSTALL | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/INSTALL b/INSTALL index 18eb67f311..284b9825ba 100644 --- a/INSTALL +++ b/INSTALL @@ -285,7 +285,8 @@ least WolfSSL 5.6.6 is needed, but a development version might be needed for some of the features: $ cd ~/build/wolfssl - $ ./configure --enable-haproxy --enable-quic --prefix=/opt/wolfssl-5.6.6/ + $ ./configure --enable-haproxy --enable-quic \ + --prefix=/opt/wolfssl-5.6.6/ EXTRA_CFLAGS=-DWOLFSSL_GETRANDOM=1 $ make -j $(nproc) $ make install That's interesting, however I'm surprised the init does not work before the chroot, we are doing a RAND_bytes() with OpenSSL before the chroot to achieve this. I'll check if we can do something like this instead of needing a explicit option, but if that's not possible we will require GETRANDOM in the --enable-haproxy build option. -- William Lallemand
Re: [RFC PATCH] DOC: httpclient: add dedicated httpclient section
Hello Lukas, On 2024-01-30 22:17, Lukas Tribus wrote: Move httpclient keywords into its own section and explain adding an introductory paragraph. Also see Github issue #2409 Should be backported to 2.6 ; but note that: 2.7 does not have httpclient.resolvers.disabled 2.6 does not have httpclient.retries and httpclient.timeout.connect --- doc/configuration.txt | 131 ++ 1 file changed, 69 insertions(+), 62 deletions(-) diff --git a/doc/configuration.txt b/doc/configuration.txt index 208b474471..402fa3d317 100644 --- a/doc/configuration.txt +++ b/doc/configuration.txt @@ -58,6 +58,7 @@ Summary 3.8. HTTP-errors 3.9. Rings 3.10. Log forwarding +3.11. httpclient I replaced the title by "HTTPClient tuning" [...] +3.11. httpclient + + +httpclient is an internal HTTP library, it can be used by various subsystems, +for example in LUA scripts. httpclient is not used in the data path, in other +words it has nothing with HTTP traffic passing through HAProxy. + I replaced "httpclient" by "HTTPClient" to match the lua documentation, and separated the httpclient.* keywords in the global index in a "* HTTPClient". That would be clear enough, thanks! I pushed it to master. I also feel like the "3. Global parameters" section derived a long time ago, some subsections are describing other configuration sections like "userlists", "peers", "mailers", "programs" etc. instead of keywords from the global section, which is confusing. Maybe we should try to clean this up. Regards, -- William Lallemand
Re: [PATCH 0/1] Update ssl_fc_curve/ssl_bc_curve sample fetch
On 2024-01-08 21:01, Mariam John wrote: Thank you Willy for the update. Appreciate it. Please take your time. I totally understand. Just wanted to make sure it wasn’t lost or forgotten about. Thank you once again. Regards, Mariam. Hello Mariam, Thank you for your contribution, I merged your patch with some small changes: - aligned the git commit message to 80 columns - removed the "BUG" tag in the subject since this is not a bug - moved back the nid variable because in C90 you can't mix declaration and code, but added __maybe_unused to avoid the warning. This will be backported in 2.8. I missed the alignment and indentation in your first contribution, in HAProxy we are using tabs for indentation and spaces for alignment, so I made a cleanup patch to switch to tabs. Regards, -- William Lallemand
Re: [PATCH 0/1] Update ssl_fc_curve/ssl_bc_curve sample fetch
On 2023-12-20 06:21, Mariam John wrote: Update ssl_fc_curve/ssl_fc_curve to use `SSL_get0_group_name` function (available from the OpenSSL v3.2 release onwards) to get the curve name. For OpenSSL versions >=3.0 and <3.2, we will continue to use `SSL_get_negotiated_group` to get the curve name. Mariam John (1): BUG/MINOR: ssl: Update ssl_fc_curve/ssl_bc_curve to use SSL_get0_group_name reg-tests/ssl/ssl_curve_name.vtc | 4 ++-- src/ssl_sample.c | 33 +++- 2 files changed, 30 insertions(+), 7 deletions(-) Hello Mariam, I'm fine with the SSL_get0_group_name() change, however if it introduces a change of behavior I can't get this backported in stable branches. It's probably better if you do it the other way, keeping the format from SSL_get_negotiated_group() while using SSL_get0_group_name() so people don't have surprises when upgrading their OpenSSL. Regards, -- William Lallemand
Re: Wildcards vs concrete SNIs in crt-list
On 12/8/23 10:55, Lowin, Patrick wrote: Dear community, we are using the crt-list for different mTLS configs with the same certificate. I’d like to align on some details combining wildcard and tenant-specific SNIs. From current experiments with 2.7.10, the order of the crt-list seems not to matter but the best-fitting SNI is chosen: # crt-list: /my-domain.pem [verify none] *.my.domain /my-domain.pem [verify optional ca-file/some-ca.pem] test123.my.domain # connection to abc.my.domain offers no CAs as expected # connection to test123.my.domain offers the CA as desired IIRC, this was different in the past, the wildcard entry was used and also no CAs were offered for test123. Does somebody have more implementation details on this? Can I rely on my observations for all crt-list properties, like ciphers and others? Best regards, Patrick Hello Patrick, I don't recall this part being changed, it could have been in a bugfix though. The only big change that was made "recently" is a fix of the inconsistency in the exclusion system which was described in https://github.com/haproxy/haproxy/issues/818 In a crt-list, each line generates a SSL_CTX structure, this structure is associated to a SNI filter, the ca-file is then applied to this SSL_CTX. During the Client Hello callback, HAProxy will first try to chose the exact SNI match, if not found, it will try to find a wildcard which can match, and will check if your sni was not excluded of the wildcard with a negative (!). Signature Algorithms and Ciphers are used when there are multiple matches for a SNI, for example if you have an ECDSA certificate and an RSA one, it will decide which one to chose. Once the SNI is found and the SSL_CTX is chosen, the handshake will continue with this SSL_CTX, and the parameters between square brackets were applied to this SSL_CTX so openssl is doing his magic itself here. I don't know if this is enough details, don't hesitate if you want to known more. -- William Lallemand
Re: [PATCH 1/1] CI: switch aws-lc builds to "latest" semantic
Hi Ilya,
On Thu, Nov 23, 2023 at 06:57:52PM +0100, Ilya Shipitsin wrote:
> for development branches let's use "latest" and fixed for stable
>
> LibreSSL-3.6.0 had some regression, it was fixed in 3.6.1, let us
> switch back to the latest LibreSSL available
I think you made a mistake, doesn't seem related to libreSSL at all.
> ---
> .github/matrix.py | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/.github/matrix.py b/.github/matrix.py
> index b5a971c5a..2d1831a4d 100755
> --- a/.github/matrix.py
> +++ b/.github/matrix.py
> @@ -195,7 +195,6 @@ def main(ref_name):
> "OPENSSL_VERSION=1.1.1s",
> "QUICTLS=yes",
> "WOLFSSL_VERSION=5.6.4",
> -"AWS_LC_VERSION=1.16.0",
> # "BORINGSSL=yes",
> ]
>
> @@ -203,6 +202,11 @@ def main(ref_name):
> ssl_versions = ssl_versions + [
> "OPENSSL_VERSION=latest",
> "LIBRESSL_VERSION=latest",
> +"AWS_LC_VERSION=latest",
> +]
> +else: # stable branch
> +ssl_versions = ssl_versions + [
> +"AWS_LC_VERSION=1.17.3",
> ]
>
> for ssl in ssl_versions:
> @@ -213,6 +217,8 @@ def main(ref_name):
> flags.append("USE_OPENSSL_WOLFSSL=1")
> if "AWS_LC" in ssl:
> flags.append("USE_OPENSSL_AWSLC=1")
> +if "latest" in ssl:
> +ssl = determine_latest_aws_lc(ssl)
> if ssl != "stock":
> flags.append("SSL_LIB=${HOME}/opt/lib")
> flags.append("SSL_INC=${HOME}/opt/include")
Well, the idea was to build the "latest" aws-lc outside the push CI, so
we are already doing this here:
http://github.com/haproxy/haproxy/blob/master/.github/workflows/aws-lc.yml
I'm not really confortable with having everything in "latest" in the
master in fact, we already have the "openssl-3.2.0-*"
builds for a while without even testing 3.1 anymore, and I didn't
noticed.
That's a problem, maybe we should put the "latest" builds in a daily
build so it can evolve on its own without impacting the dev.
Having a library which change its version between 2 pushes can be quite
confusing, even more if the library broke something, usually you want to
test your code when you push in master, not the libraries!
For example we could have had build breakage when switching
automatically to 3.2-alpha them 3.2-beta etc.
But since we didn't had any problem for now, maybe we could just try it,
it can be reverted easily anyway...
--
William Lallemand
Re: USE_QUIC in haproxy debian packages?
On Wed, Nov 22, 2023 at 11:02:23PM +0100, Vincent Bernat wrote: > On 2023-11-22 09:13, William Lallemand wrote: > > Hello Vincent, > > > > [HAProxy list in cc] > > > > We backported the USE_QUIC_OPENSSL_COMPAT build option in HAProxy 2.8.4, > > so we can build with USE_QUIC using OpenSSL without a patched version > > of OpenSSL. > > > > Unfortunately we can't activate this option in the default build, > > because it's not compatible with other openssl libraries (quictls, > > libressl and boringssl don't use a specific build option). And using > > only a Makefile we can't really autodetect the libraries to activate an > > option. > > > > Do you think that's possible to activate these 2 options for the next > > 2.8 debian/ubuntu packages? > > Yes, I'll upload shortly, plus for jemalloc. > Thanks! -- William Lallemand
USE_QUIC in haproxy debian packages?
Hello Vincent, [HAProxy list in cc] We backported the USE_QUIC_OPENSSL_COMPAT build option in HAProxy 2.8.4, so we can build with USE_QUIC using OpenSSL without a patched version of OpenSSL. Unfortunately we can't activate this option in the default build, because it's not compatible with other openssl libraries (quictls, libressl and boringssl don't use a specific build option). And using only a Makefile we can't really autodetect the libraries to activate an option. Do you think that's possible to activate these 2 options for the next 2.8 debian/ubuntu packages? Regards, -- William Lallemand
Re: soft-stop stops runtime API, should that be optional?
On Tue, Nov 14, 2023 at 05:18:14PM -0800, Abhijeet Rastogi wrote:
> Hi,
>
> I'll appreciate a response on this, I was unable to get any guidance from
> docs.
>
> Thanks
>
> On Tue, Nov 7, 2023 at 3:37 PM Abhijeet Rastogi
> wrote:
>
> > Hi HAproxy community,
> >
> > In our HAproxy deployment, access to runtime API is extremely critical, it
> > is used for:-
> > - collecting metrics
> > - managing servers in a backend (SoT is not DNS, so we have to use runtime
> > API), etc
> >
> > I observed that, when soft-stop is in progress, we get the following error
> > while performing a connect.
> >
> > connect(5, {sa_family=AF_UNIX, sun_path="path/to/haproxy.sock"}, 60) = -1
> > ECONNREFUSED (Connection refused)
> > recvfrom(3, 0x7ffcc675fe10, 519, MSG_DONTWAIT, NULL, NULL) = -1 EAGAIN
> > (Resource temporarily unavailable)
> >
> > Due to this, we're unable to perform any operations or collect metrics
> > while haproxy is in soft stop, for us, that's a long time as we use the
> > current settings.
> >
> > close-spread-time 10m
> > hard-stop-after 11m
> >
> > "stats socket" (unix socket) is configured on one of the production
> > frontends, we're using version "version 2.8.0-01b97d-15 2023/09/26".
> >
> > Will it make sense if HAproxy had an option to not disable runtime API
> > during soft-stop, perhaps an argument
> > While exploring the code, I noticed that the soft-stop code stops all
> > "stoppable
> > listeners"
> > <https://sourcegraph.com/github.com/haproxy/haproxy/-/blob/src/proxy.c?L2280>,
> > I wonder if there's a way to make a listener non-stoppable?
> >
> > Are there any workarounds to getting around this limitation, while also
> > retaining the soft-stop behavior?
> > Our reason to use soft-stop is to do best-effort into gracefully draining
> > client connections (send Connection: close). We also don't have a way to
> > drain H2 connections proactively, but that's a discussion for another day.
> >
> > Cheers,
> > Abhijeet (https://abhi.host)
> >
>
Hi Abhijeet,
A soft stop would close the stats socket of the leaving process, so if
you are not attached anymore to the socket you can't do much. If you
keep a connection to the socket you won't have the problem, but you need
to configure the right timeout so the connection won't be closed.
A cleaner solution is to use the master CLI instead of the stats
socket, this is a socket which is attached to the master process, and
which is able to connect to leaving processes.
http://docs.haproxy.org/2.8/management.html#9.4
Regards,
--
William Lallemand
Re: Can't display the certificate: Not found or the certificate is a bundle!
On Tue, Nov 14, 2023 at 02:21:44PM +0100, Christoph Kukulies wrote: > Thanks. > > I did a fresh > > acme.sh --issue -d domain ... --keylength 2048 > with prior revoking the certificates since I was a bit unsure what the > partially exposing of my provate key was concerned - thanks, Shawn. > > I went back to the Wiki and found the necessary steps there: > > DEPLOY_HAPROXY_HOT_UPDATE=yes > DEPLOY_HAPROXY_STATS_SOCKET=/var/run/haproxy/admin.sock > DEPLOY_HAPROXY_PEM_PATH=/etc/haproxy/certs acme.sh --deploy -d > www.mydomain.org --deploy-hook haproxy > [Tue Nov 14 02:07:26 PM CET 2023] Deploying PEM file > [Tue Nov 14 02:07:26 PM CET 2023] Moving new certificate into place > [Tue Nov 14 02:07:26 PM CET 2023] Reload successful > [Tue Nov 14 02:07:26 PM CET 2023] Success > acme@mail:~/.acme.sh$ ls -l /etc/haproxy/certs > total 12 > -rw-rw-r-- 1 acme acme 8489 Nov 14 14:07 www.mydomain.org.pem > > Christoph Kukulies > k...@kukulies.org > > > > This file seems to be assembled by the deploy script. (since it contains the > private key). > > So far so good for the first. Got to implement the renewal mechanism now. I don't think you followed correctly the instruction of the wiki, the DEPLOY_HAPROXY_HOT_UPDATE=yes option is supposed to prevent the reload by using the CLI. It does not look like this is working here. You must have skipped the installation of the deploy script. https://github.com/haproxy/wiki/wiki/Letsencrypt-integration-with-HAProxy-and-acme.sh#acmesh-installation -- William Lallemand
Re: Should we change the -c output?
On Tue, Nov 14, 2023 at 02:32:40AM -0500, John Lauro wrote: > I like the default message. If you want to suppress it, then you can use -q. > Having some standard output that can be suppressed with -q is also > fairly standard for UNIX commands. > In haproxy we have these two flags: -q is meant to suppress all the messages, even when the configuration is wrong, that's not the same thing as displaying only the errors. -V is meant to add more output than the default. Till 2.8, the systemd unit was not displaying the errors upon a reload because it was checking the configuration with -q, I'm surprised nobody reported it, because that's really a pain to have a process which reloads incorrectly without showing any error. Problem is, when removing the -q, the script adds "Configuration is valid" to the logs for every reloads, which are already a bit heavy for just a reload. Using -q for this was a problem, so I'd better not do it. I'm not talking about suppressing the message, just hiding the "valid" message by default, without -V. All other warnings and alerts are still outputed, so it's easy to see if you broke something. -- William Lallemand
Re: Can't display the certificate: Not found or the certificate is a bundle!
On Mon, Nov 13, 2023 at 10:46:08AM +0100, Christoph Kukulies wrote: > > Am 13.11.2023 um 10:09 schrieb William Lallemand : > >> > >> acme@mail:~$ echo "show ssl cert /etc/haproxy/certs/mydomain.org.pem" | > >> socat /var/run/haproxy/admin.sock - > >> Can't display the certificate: Not found or the certificate is a bundle! > >> > > acme@mail:~/.acme.sh/www.mydomain.org_ecc$ echo "show ssl cert " | socat > /var/run/haproxy/admin.sock - > # filename > /etc/haproxy/certs/fullchain.pem > /etc/haproxy/certs/fullchain_ec.pem > > > Well, you can't display /etc/haproxy/certs/mydomain.org.pem because it's not in haproxy. Can you share the output of your deploy acme.sh command as well as your haproxy configuration? -- William Lallemand
Re: Can't display the certificate: Not found or the certificate is a bundle!
On Sat, Nov 11, 2023 at 10:26:33AM +0100, Christoph Kukulies wrote: > I'm using haproxy2.8 and I have configured the acme.sh challenge to fetch > the certificate, following this wiki here: > https://github.com/haproxy/wiki/wiki/Letsencrypt-integration-with-HAProxy-and-acme.sh > > Once I get to the point to test the certificate, I'm getting: > > acme@mail:~$ echo "show ssl cert /etc/haproxy/certs/mydomain.org.pem" | socat > /var/run/haproxy/admin.sock - > Can't display the certificate: Not found or the certificate is a bundle! > > > The file is definitely there and the command works an a different file, when > I apply it to the previously used certificate fullchain.pem. > The file which is not working, has the following structure: "show ssl cert" shows the certificate in the haproxy memory, and not on the filesystem. Start by doing "show ssl cert" without any argument to see the list of certificates whcih were loaded by haproxy. -- William Lallemand
Re: Should we change the -c output?
On Mon, Nov 13, 2023 at 09:52:57AM +0100, Baptiste wrote: > On Thu, Nov 9, 2023 at 5:00 PM William Lallemand > wrote: > > > Hello, > > > > haproxy -c seems to be too verbose in the systemd logs by > > showing "Configuration file is valid" for every reloads. > > > > Is there anyone against removing this message by default? > > This will still output the alerts and warnings if some exists but the > > "Configuration file is valid" message will only be displayed in > > combination with -V. > > > > People tend to use the return code of the command and not the output, > > but I prefer to ask. > > > > Change will only be applied starting from 2.9. Patch attached. > > > > -- > > William Lallemand > > > > Hi William, > > I used to use this message for 13 years while manually checking confs :) > I think it may impact admins / devs who run these manual checks, but not > too hard as we all look for "ERROR" or "WARNING" by default. > I think it's "ok" to change this. I will just miss it :D > > Baptiste That's what I thought either, and I like it since it's a little bit more like an UNIX command, which displays nothing when everything is correct. I pushed the patch, thanks! -- William Lallemand
Should we change the -c output?
Hello,
haproxy -c seems to be too verbose in the systemd logs by
showing "Configuration file is valid" for every reloads.
Is there anyone against removing this message by default?
This will still output the alerts and warnings if some exists but the
"Configuration file is valid" message will only be displayed in
combination with -V.
People tend to use the return code of the command and not the output,
but I prefer to ask.
Change will only be applied starting from 2.9. Patch attached.
--
William Lallemand
>From d189f5473f0ed0594c693646d424d0a9e03eabaf Mon Sep 17 00:00:00 2001
From: William Lallemand
Date: Thu, 9 Nov 2023 14:48:50 +0100
Subject: [PATCH] MEDIUM: startup: MODE_CHECK is quiet by default
MODE_CHECK does not output "Configuration file is valid" by default
anymore. To display this message the -V option must be used with -c.
However the warning and errors are still output by default if they
exist.
This allows to clean the output of the systemd unit file with is doing a
-c.
---
src/haproxy.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/haproxy.c b/src/haproxy.c
index 7a4f49fa6..d728f0c21 100644
--- a/src/haproxy.c
+++ b/src/haproxy.c
@@ -2374,7 +2374,8 @@ static void init(int argc, char **argv)
if (pr || px) {
/* At least one peer or one listener has been found */
- qfprintf(stdout, "Configuration file is valid\n");
+ if (global.mode & MODE_VERBOSE)
+qfprintf(stdout, "Configuration file is valid\n");
deinit_and_exit(0);
}
qfprintf(stdout, "Configuration file has no error but will not start (no listener) => exit(2).\n");
--
2.39.2
Re: unsupported protocol family 2 for address 'quic4@0.0.0.0:4
On Wed, Nov 08, 2023 at 04:42:00PM +0100, Christoph Kukulies wrote: > > I posted the output of haproxy -vv (on demand of William Lallemand). Maybe > you overlooked it: > That's weird, it shouldn't behave like this and I couldn't reproduce at all. > root@mail:~/haproxy-scripts# /usr/local/sbin/haproxy -vv > HAProxy version 2.8.3-d6e5cd-70 2023/10/26 - https://haproxy.org/ > <https://haproxy.org/> > Status: long-term supported branch - will stop receiving fixes around Q2 2028. > Known bugs: http://www.haproxy.org/bugs/bugs-2.8.3.html > <http://www.haproxy.org/bugs/bugs-2.8.3.html> > Running on: Linux 5.15.0-88-generic #98-Ubuntu SMP Mon Oct 2 15:18:56 UTC > 2023 x86_64 > Build options : > TARGET = linux-glibc > CPU = native > CC = cc > CFLAGS = -O2 -march=native -g -Wall -Wextra -Wundef > -Wdeclaration-after-statement -Wfatal-errors -Wtype-limits > -Wshift-negative-value -Wshift-overflow=2 -Wduplicated-cond > -Wnull-dereference -fwrapv -Wno-address-of-packed-member -Wno-unused-label > -Wno-sign-compare -Wno-unused-parameter -Wno-clobbered > -Wno-missing-field-initializers -Wno-cast-function-type -Wno-string-plus-int > -Wno-atomic-alignment > OPTIONS = USE_OPENSSL=1 USE_ZLIB=1 USE_SYSTEMD=1 USE_QUIC=1 USE_PCRE2_JIT=1 > DEBUG = > > > And the install script installed the following config file (kindly > overwriting my own config, thank you :-(. ) > You should probably use a packaged version of haproxy. > global > maxconn 64 > daemon > log 127.0.0.1 len 65535 format rfc5424 local0 > log 127.0.0.1 len 65535 format rfc5424 local1 notice > > > defaults > log global > option httplog > mode http > timeout connect 5s > timeout client 15s > timeout server 120s > timeout http-keep-alive 5s > timeout check 9990 > > > frontend web80 > bind 0.0.0.0:80 name web80 > default_backend be-local-81 > > frontend web > description One frontend to rule them all > bind 0.0.0.0:443 name web443 ssl crt > /etc/ssl/certs/local/selfsigned.pem alpn h2,http/1.1 npn h2,http/1.1 > allow-0rtt curves secp521r1:secp384r1 > bind quic4@0.0.0.0:443 name quic443 ssl crt > /etc/ssl/certs/local/selfsigned.pem proto quic alpn h3,h3-29,h3-28,h3-27 npn > h3,h3-29,h3-28,h3-27 allow-0rtt curves secp521r1:secp384r1 > http-response add-header alt-svc 'h3=":443"; ma=7200,h3-29=":443"; > ma=7200,h3-Q050=":443"; ma=7200,h3-Q046=":443"; ma=7200,h3-Q043=":443"; > ma=7200,quic=":443"; ma=7200' > default_backend be-local-81 > stats enable > stats uri /hapeek > stats refresh 15 > > backend be-local-81 > option httpchk > server localhost 127.0.0.1:81 > > > which leads to haproxy failing on startup: > > Nov 8 16:38:28 mail haproxy[101582]: [ALERT](101582) : parsing > [/etc/haproxy/haproxy.cfg:26] : 'bind' : unsupported protocol family 2 for > address 'quic4@0.0.0.0:443' > > So what can I do about it other than trusting upon the scripts and configs > to work? Or ask here for help? I don't know how you are running your configuration, and what your scripts does. I can't reproduce at all the problem with the given configuration. How are you starting haproxy? Could you run `/usr/local/sbin/haproxy -c -f /etc/haproxy/haproxy.cfg` ? -- William Lallemand
Re: FYI: OpenWrt switches from wolfssl to mbedtls as default
On Mon, Oct 16, 2023 at 02:40:37PM +0200, William Lallemand wrote: > On Fri, Oct 13, 2023 at 04:30:37PM +0200, William Lallemand wrote: > > > and TLSv1.3 is a must-have, > > > > I don't get this point, mbedtls supports TLS 1.3 so I don't really > > understand what they are talking about. Maybe they disable TLS 1.3 on > > the 2.28 version for some rease but I couldn't find any detail. > > > > > > Regarding this, I found in the changelog that mbedtls provides a minimum > viable implementation of the TLS 1.3 protocol starting from the 3.1.0 > version, so it explains everything. > > https://github.com/Mbed-TLS/mbedtls/releases/tag/v3.1.0 > > Mbed TLS provides a minimum viable implementation of the TLS 1.3 > > protocol. See docs/architecture/tls13-support.md for the definition of > > the TLS 1.3 Minimum Viable Product (MVP). The MBEDTLS_SSL_PROTO_TLS1_3 > > configuration option controls the enablement of the support. The APIs > > mbedtls_ssl_conf_min_version() and mbedtls_ssl_conf_max_version() allow > > to select the 1.3 version of the protocol to establish a TLS connection. > > > > Related to this discussion, I think that's a good example: https://github.com/wolfSSL/wolfssl/issues/6928 -- William Lallemand
Re: unsupported protocol family 2 for address 'quic4@0.0.0.0:4
On Wed, Nov 08, 2023 at 11:27:49AM +0100, Christoph Kukulies wrote: > parsing [/etc/haproxy/haproxy.cfg:60] : 'bind' : unsupported protocol family > 2 for address 'quic4@0.0.0.0:4> > Nov 08 11:16:54 mail. > > > I'm using sample.haproxy.cfg from Shawns haproxy-scripts and there the line: > > bind quic4@0.0.0.0:443 name quic443 ssl crt crt > /etc/haproxy/fullchain.pemproto quic alpn h3 npn h3 allow-0rtt curves > secp521r1:secp384r1 > > -- > Christoph > > Did you compile haproxy with USE_QUIC=1? look at haproxy -vv to check if you have quic support. -- William Lallemand
Re: No Private Key found in '/etc/letsencrypt/live/www.mydomain.org/fullchain.pem.key
On Wed, Nov 01, 2023 at 03:48:56PM -0600, Shawn Heisey wrote: > The LE fullchain file does not contain the key. It contains 3 > certificates. ... the server cert, the issuing cert, and the root cert > ... which is not what you want. For letsencrypt, the file that you give > to haproxy must contain the server cert, the issuing cert, and the > private key. Actually you can separate the key from the chain with haproxy, but without the configuration it's difficult to know what it's trying to load. http://docs.haproxy.org/2.8/configuration.html#ssl-load-extra-files With the 'key' option it's able to load a 'file.pem.key' if you specified 'crt file.pem' in your configuration > You do not want to include the root certificate. It will be ignored > by the browser even if it is included, but it will probably slow down > TLS negotiation by a small amount. The presence of the root > certificate in the TLS handshake should not actually break anything in > most cases, but it could result in a lower score on the Qualys Labs > SSL test. > You can also ask haproxy to ignore the root CA in the configuration: http://docs.haproxy.org/2.8/configuration.html#ssl-skip-self-issued-ca > When my renewal script finishes, I have a file containing four things: > The server cert, the issuing cert, the private key, and a unique 4096 > bit DHPARAM. This combination is ideal for haproxy. > > The version of certbot that I am using generates 256-bit ECDSA keys by > default. You might be thinking that a 256 bit ECDSA key cannot be as > secure as a 2048 bit RSA key, but that is incorrect: > > https://www.baeldung.com/cs/encryption-asymmetric-algorithms#3-key-length > > Some of the equipment I use will not work with ECDSA keys, so I have a > second cert with a subset of names that I build using 4096 bit RSA. > There is a lot of possibility to configure this, we are trying to move forward to a configuration where we can specifiy files separately so there would be nothing to do in the future, but unfortunately there is still development to do. -- William Lallemand
Re: No Private Key found in '/etc/letsencrypt/live/www.mydomain.org/fullchain.pem.key
Hello, Please share at least your haproxy configuration and version and what you are trying to do, your mail is really unclear. On Wed, Nov 01, 2023 at 12:20:35PM +0100, Christoph Kukulies wrote: > 'bind *:443' : No Private Key found in > '/etc/letsencrypt/live/www.mydomain.org/fullchain.pem.key'. > > I have the following in my > /etc/letsencrypt/live/www.mydomain.org: > > lrwxrwxrwx 1 root root 41 Oct 23 17:22 cert.pem -> > ../../archive/www.mydomain.org/cert12.pem > lrwxrwxrwx 1 root root 42 Oct 23 17:22 chain.pem -> > ../../archive/www.mydomain.org/chain12.pem > lrwxrwxrwx 1 root root 46 Oct 23 17:22 fullchain.pem -> > ../../archive/www.mydomain.org/fullchain12.pem > lrwxrwxrwx 1 root root 13 Nov 1 12:12 fullchain.pem.key -> fullchain.pem > lrwxrwxrwx 1 root root 44 Oct 23 17:22 privkey.pem -> > ../../archive/www.mydomain.org/privkey12.pem > lrwxrwxrwx 1 root root 11 Nov 1 12:11 privkey.pem.key -> privkey.pem > -rw-r--r-- 1 root root 692 Nov 13 2021 README > > > Before I had no .key files in there. > > Since I added the symbolic links to the files with .key extension I got an > additional line in the log: > > Nov 1 12:13:40 mail haproxy[103552]: > '/etc/letsencrypt/live/www.mydomain.org/fullchain.pem.key' is present but > cannot be read or parsed'. > > I'm a bit clueless now. Help appreciated. > > -- > Christoph > -- William Lallemand
Re: 2.9-dev8: ha_panic from libcrypto/libssl (Ubuntu 22.04, OpenSSL 3.0.2)
On Tue, Oct 24, 2023 at 02:03:03AM +0300, Valters Jansons wrote: > Hello, > Hello, > > We are running 2.9-dev8 for the server connection close fix for > "not-so-great" gRPC clients. We just experienced an ha_panic seemingly > triggered from OpenSSL 3. This is a fairly default Ubuntu 22.04 > system, with locally built HAProxy package (as there are no "official" > dev builds). > There is a list of packages available there: https://github.com/haproxy/wiki/wiki/Packages Specifically I maintain a build for ubuntu and debian, based of the latest commit of the master branch, the build is trigered for each push. You can install them from here: https://software.opensuse.org/download/package?package=haproxy=home%3Awlallemand The package is based on the debian one, here the build options: https://github.com/wlallemand/haproxy-nightly-build/blob/master/debian/rules#L10 -- William Lallemand
Re: [PATCH] Added support for Arrays in sample_conv_json_query in sample.c
On Mon, Sep 25, 2023 at 01:30:53PM +, Jens Popp wrote: > Method now returns the content of Json Arrays, if it is specified in > Json Path as String. The start and end character is a square bracket. Any > complex object in the array is returned as Json, so that you might get Arrays > of Array or objects. Only recommended for Arrays of simple types (e.g., > String or int) which will be returned as CSV String. Also updated > documentation and fixed issue with parenthesis and other changes from > comments. > Hello Jens, Thank you for you patch, I just pushed it into master. I also added a reg-test into the patch: https://github.com/haproxy/haproxy/commit/f216b45bb94475aafcdd855fbf358cc812eb1d33#diff-c29792e4360cebe8528660d3a2da5c0401201d3c0490bf72cfe7b6cef0cb34e3R101 Don't forget to add one next time you contribute so we can easily test if we broke the feature by accident! Regards, -- William Lallemand
Re: FYI: OpenWrt switches from wolfssl to mbedtls as default
On Fri, Oct 13, 2023 at 04:30:37PM +0200, William Lallemand wrote: > > and TLSv1.3 is a must-have, > > I don't get this point, mbedtls supports TLS 1.3 so I don't really > understand what they are talking about. Maybe they disable TLS 1.3 on > the 2.28 version for some rease but I couldn't find any detail. > > Regarding this, I found in the changelog that mbedtls provides a minimum viable implementation of the TLS 1.3 protocol starting from the 3.1.0 version, so it explains everything. https://github.com/Mbed-TLS/mbedtls/releases/tag/v3.1.0 > Mbed TLS provides a minimum viable implementation of the TLS 1.3 > protocol. See docs/architecture/tls13-support.md for the definition of > the TLS 1.3 Minimum Viable Product (MVP). The MBEDTLS_SSL_PROTO_TLS1_3 > configuration option controls the enablement of the support. The APIs > mbedtls_ssl_conf_min_version() and mbedtls_ssl_conf_max_version() allow > to select the 1.3 version of the protocol to establish a TLS connection. > -- William Lallemand
Re: FYI: OpenWrt switches from wolfssl to mbedtls as default
On Fri, Oct 13, 2023 at 11:39:59AM +, Lukas Tribus wrote: > Hello, > > > an interesting move from the OpenWRT project: > > > > Switch from wolfssl to mbedtls as default > > = > > > > OpenWrt has transitioned its default cryptographic library from wolfssl > > to mbedtls. This shift brings several changes and implications: > > > > * Size Efficiency: mbedtls is considerably smaller, making it an > > optimal choice for systems where storage space is paramount. > > * LTS and ABI Stability: mbedtls consistently provides updates via its > > Long Term Support (LTS) branch, ensuring both security and a stable > > application binary interface (ABI). In contrast, wolfssl does not > > offer an LTS release, and its stable ABI is limited to a specific set > > of functions. > > * TLS 1.3 Support: Users should be aware that mbedtls 2.28 no longer > > supports TLS 1.3. > > > > While mbedtls is now the default, users who have specific needs or > > preferences can still manually switch back to wolfssl or choose openssl. > > As per: > http://lists.openwrt.org/pipermail/openwrt-announce/2023-October/47.html > > Size Efficiency does not matter a lot in the context of haproxy, It depends, OpenSSL uses a lot of memory and a smaller footprint is interesting when you want more simultaneous sessions. > and TLSv1.3 is a must-have, I don't get this point, mbedtls supports TLS 1.3 so I don't really understand what they are talking about. Maybe they disable TLS 1.3 on the 2.28 version for some rease but I couldn't find any detail. > but I'm surprisedFYI about the point about LTS > and ABI Stability in wolfssl and I'm wondering if this is really the > case? > To be honest I don't know well enough the wolfssl release cycle, but they don't announce publicly LTS versions for their opensource versions, if you want that you must have commercial contract. Regarding the ABI, it seems to me that are a lot of changes, but it makes sense since there is no LTS> We are using the openssl compatibility API for HAProxy, the API is not supposed to change a lot, but the ABI change fromt time to time. -- William Lallemand
USE_QUIC=1 support for awslc
Hello, I fixed the build for USE_QUIC=1 and AWSLC which is limited like Ilya mentionned. For now: - 0RTT was disabled. - TLS1_3_CK_CHACHA20_POLY1305_SHA256, TLS1_3_CK_AES_128_CCM_SHA256 were disabled - clienthello callback is missing, certificate selection could be limited (RSA + ECDSA at the same time) I could made some tests with curl --http3 and firefox which seems to be working, no chance with chrome yet. At least we activated the build so I'll check the next steps: > чт, 7 сент. 2023 г. в 00:05, Hopkins, Andrew : > > 1. AWS-LC plumbs these two algorithms through the EVP_CIPHER API. This is > > useful for HAProxy and other AWS-LC customers, but is the most work That would be the best from a maintainance point of view. > > 2. HAProxy adopts AWS-LC’s (and BoringSSL’s) AEAD API > > Well, since it exists in awslc, libressl and boringssl, maybe we could spend some time on this, I'll check if this is complicated to integrate in our current code. > > 3. HAProxy turns off ChaCha Poly and AES CCM support in quic when built > > with AWS-LC That's the current status for now. -- William Lallemand
Re: OCSP update restarts all proxies
On Wed, Oct 04, 2023 at 08:52:39AM -0600, Shawn Heisey wrote: > On 10/4/23 05:34, Remi Tricot-Le Breton wrote: > > You just have to run the following commands : > > > > $ echo "update ssl ocsp-response " | socat > > /path_to_socket/haproxy.sock - > > When I do this, the update is successful and shows in the logfile > created by rsyslogd ... but unlike when haproxy does the automatic > hourly update, there is no service reload, so the proxies are not stopped. > > When my old ocsp updating script sent an ocsp response to the stats > socket, there was no service reload either. > > I couldn't follow what's in the src/ssl_ocsp.c file. It has been a > REALLY long time since I actually wrote C code myself. I was hoping to > find out whether or not that code was initiating a service reload when > systemd support is enabled. > > I have tried to find something external to haproxy that might be > initiating the reload, but I haven't found anything. > > Thanks, > Shawn Hello Shawn, Nothing in haproxy initiate a service reload, are sure you don't have an external process which is doing it? The systemd support within HAProxy is only meant to provide a status to systemd, it does not send it actions. HAProxy only sends a "READY=1" status to systemd, so if you are seeing a "Reloaded" message from systemd, it was sent by something external to HAProxy. And it would be a `systemctl reload` action, not a manual kill -USR2 signal. Regards, -- William Lallemand
Re: HaProxy does not updating DNS cache
On Wed, Sep 13, 2023 at 12:39:36PM +, Henning Svane wrote: > Hi > > I have tried using a DNS with a TTL of 600 sec. and the DNS changes > once in a while, but every time I have to restart Haproxy to get the > updated DNS to work. Even if I wait for hours. I can see with > nslookup that the server can see the updated DNS correctly. > > So is there a setting that makes HaProxy TTL aware? So HaProxy reloads > the DNS record every time the TTL expires. > > Regards Henning DNS are resolved at startup, if you want dynamic resolving you need to use a resolvers section [1] and the resolvers keyword on server lines. [1]: https://docs.haproxy.org/2.8/configuration.html#resolvers%20(The%20resolvers%20section) -- William Lallemand
Re: [PATCH] BUILD: ssl: Build with new cryptographic library AWS-LC
On Tue, Sep 05, 2023 at 11:56:26PM +, Hopkins, Andrew wrote: > I split up the remaining CI changes into 4 new attached patches. The > latest changes are still passing on my fork > https://github.com/andrewhop/haproxy/actions/runs/6090899582. > Thanks, I just merged them! > I was hoping to take advantage of the better HAProxy support in > AWS-LC's CI but I'm running into some issues in > https://github.com/aws/aws-lc/pull/1174 I was wondering if you had any > pointers of what to look at. I think this is CodeBuild specific issue > since the tests pass in HAProxy's CI and when I run AWS-LC's CI > locally. I just can't figure out what CodeBuild might be doing to mess > with the results. > > Looking at the log for mcli_start_progs.vtc the two sleep programs are > started as expected but the overall process returns the wrong exit > code (0x0 instead of 0x82). Does anything stand out to you as weird > looking? > I never used CodeBuild so I'm not aware on any timers or process limitation but that could be something like that. >From what I understand from the trace, I think every processes received a SIGTERM. You can see 2 "Exiting Master process..." and the first one is before the "kill" from VTest which is suppose to send a SIGINT so it was probably sent outside the test. This test should finish like this: *** h1debug|:MASTER.accept(0008)=000e from [127.0.0.1:41542] ALPN= *** h1debug|:MASTER.srvcls[000e:] h1CLI connection normally closed *** h1CLI closing fd 9 h1CLI recv|# h1CLI recv|357949 master 0 [failed: 0] 0d00h00m00s 2.9-dev4-06d369-78 h1CLI recv|# workers h1CLI recv|357955 worker 0 0d00h00m00s 2.9-dev4-06d369-78 h1CLI recv|# programs h1CLI recv|357953 foo 0 0d00h00m00s - h1CLI recv|357954 bar 0 0d00h00m00s - h1CLI recv| *** h1debug|0001:MASTER.clicls[:] *** h1debug|0001:MASTER.closed[:] h1CLI expect match ~ ".*foo.* .*bar.* " ** h1CLI ending ** h1Wait ** h1Stop HAproxy pid=357949 h1Kill(2)=0: Success *** h1debug|[NOTICE] (357949) : haproxy version is 2.9-dev4-06d369-78 *** h1debug|[NOTICE] (357949) : path to executable is /home/wla/projects/haproxy/haproxy-community-maint/haproxy *** h1debug|[WARNING] (357949) : Exiting Master process... *** h1debug|[ALERT](357949) : Current program 'foo' (357953) exited with code 130 (Interrupt) *** h1debug|[ALERT](357949) : Current program 'bar' (357954) exited with code 130 (Interrupt) dT0.076 *** h1debug|[ALERT](357949) : Current worker (357955) exited with code 130 (Interrupt) *** h1debug|[WARNING] (357949) : All workers exited. Exiting... (130) dT0.077 h1STDOUT EOF dT0.171 ** h1WAIT4 pid=357949 status=0x8200 (user 0.058881 sys 0.026402) *top RESETTING after reg-tests/mcli/mcli_start_progs.vtc ** h1Reset and free h1 haproxy -1 dT0.172 ** s1Waiting for server (4/-1) *top TEST reg-tests/mcli/mcli_start_progs.vtc completed *diag 0.0 /usr/bin/sleep #top TEST reg-tests/mcli/mcli_start_progs.vtc passed (0.173) 0 tests failed, 0 tests skipped, 1 tests passed -- William Lallemand
Re: [PATCH] BUILD: ssl: Build with new cryptographic library AWS-LC
On Fri, Sep 01, 2023 at 01:25:55AM +, Hopkins, Andrew wrote: > Hi, Hi Andrew! > I have what I think it approaching the final 3 patches attached. I > cleaned up the first patch so it just includes the code, makefile, and > documentation changes to support AWS-LC. The second patch disables the > one FFDH test when HAPRoxy is build with AWS-LC. I merged these two ones which are fine. > Finally, the third patch does a few things: > 1. Add support to matrix.py to find the latest release of AWS-LC, it > would be a one line change to add AWS-LC to build on every push in > matrix.py in the future > 2. Update matrix.py to have a main function, > this looks like a big change but is all whitespace. I did this because > I needed a way to get the latest version in aws-lc.yml. I did that by > invoking the determine_latest_aws_lc function in the GitHub action, > I'm open to other suggestions > 3. Add a weekly build of HAProxy with > the latest release of AWS-LC with the same schedule as the other > weekly jobs: Thursdays at 00:00 > Seems like you just list what could be 3 differents patches in my opinion. :-) Also this could have been your commit message too! I didn't merged this one, there is a lot going on in there. It would be better to split them for better readibility. We encourage to write micro commits with only one feature per patch. I'm fine with the final result though, but could you split it in 3 patches? Thanks > You can see an example of the run here [1]. Also, I discovered you can > add `workflow_dispatch` to scheduled tasks so you can manually trigger > them without having to tweak the cron schedule. > > [1] https://github.com/andrewhop/haproxy/actions/runs/6044112377 > That's great, that will be useful this way! Thanks -- William Lallemand
Re: [PATCH] MINOR: properly mark the end of the CLI command in error messages
On Sat, Sep 02, 2023 at 10:05:11AM +0200, Miroslav Zagorac wrote: > Hello all, > > this is a patch related to correctly marking the end of the CLI command in the > error message in several places in the file src/ssl_ckch.c . > Thanks, merged. -- William Lallemand
Re: [PATCH 1/1] CI: fedora: fix "dnf" invocation syntax
On Fri, Aug 25, 2023 at 08:20:24AM +0200, Ilya Shipitsin wrote: > In 39e205302e8afb68d954e17944fad5f8c1587287 I erroneously used > "dnf git" instead of "dnf install" > --- > .github/workflows/fedora-rawhide.yml | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/.github/workflows/fedora-rawhide.yml > b/.github/workflows/fedora-rawhide.yml > index bf8ad3d72..aa3abc585 100644 > --- a/.github/workflows/fedora-rawhide.yml > +++ b/.github/workflows/fedora-rawhide.yml > @@ -20,7 +20,7 @@ jobs: > - uses: actions/checkout@v3 > - name: Install dependencies >run: | > -dnf -y git install 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 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 > - name: Install VTest > run: scripts/build-vtest.sh > - name: Install QuicTLS Thanks, merged. -- William Lallemand
Re: [PATCH] BUILD: ssl: Build with new cryptographic library AWS-LC
Hello, On Fri, Aug 18, 2023 at 11:32:17PM +, Hopkins, Andrew wrote: > Do you have a preference between 1 and 2? Where does that notification > go if something does break in the future? I prefer that we only do a weekly build for now, we already have too much things in the per push CI. The failures are sent via the github notifications to the maintainers. > I have added a dedicated USE_OPENSSL_AWSLC in the updated > 0001-BUILD-ssl-Build-with-new-cryptographic-library-AWS-LC.patch that > is attached. > I took this as an opportunity to add a few sanity checks > to catch obvious errors when compiling (wrong header files) or during > library startup (wrong libcrypto library). > That's great, thanks. I looks fine to me, but I would be better to split your first patch in 3 patches: - the part for the CI with scripts/build-ssl.sh and .github/matrix.py - the portage of the reg-tests - the Makefile and the .c files > I am going to be out of the office for a week so my response will be > delayed. > Ok, no worries. -- William Lallemand
Re: Old style OCSP not working anymore?
On Thu, Jul 20, 2023 at 08:27:08PM +0200, Sander Klein wrote: > On 2023-07-20 11:14, William Lallemand wrote: > > On Thu, Jul 20, 2023 at 10:23:21AM +0200, Sander Klein wrote: > >> On 2023-07-19 11:00, William Lallemand wrote: > >> "show ssl ocsp-resonse" gives me a lot of output like: > >> > >> Certificate ID key : *LONGID* > >> Certificate path : /parth/to/cert.pem > >> Certificate ID: > >> Issuer Name Hash: *HASH* > >> Issuer Key Hash: *ANOTHERHASH* > >> Serial Number: *SERIAL* > >> > > > > You should check with the path argument so it gives you the date and > > status. > > Okay, so, on HAProxy 2.8.1 with the path argument I get a correct > response: > > OCSP Response Data: > OCSP Response Status: successful (0x0) > Response Type: Basic OCSP Response > Version: 1 (0x0) > Responder Id: C = US, O = Let's Encrypt, CN = R3 > Produced At: Jul 18 07:22:00 2023 GMT > Responses: > Certificate ID: >Hash Algorithm: sha1 >Issuer Name Hash: 48DAC9A0FB2BD32D4FF0DE68D2F567B735F9B3C4 >Issuer Key Hash: 142EB317B75856CBAE500940E61FAF9D8B14C2C6 >Serial Number: 0323CDB93D804581B31A8D0CB737AD57728D > Cert Status: good > This Update: Jul 18 07:00:00 2023 GMT > Next Update: Jul 25 06:59:58 2023 GMT > > Signature Algorithm: sha256WithRSAEncryption > 37:d6:5a:2a:f8:b6:36:a7:5b:b8:1a:7b:24:39:a4:33:61:b7: > 68:85:50:bf:5f:cd:e7:17:1b:9b:cb:c5:fa:31:60:ad:96:71: > f3:39:aa:09:f1:d2:5f:fa:d1:29:a6:3e:27:75:b7:f4:68:7b: > 83:d1:00:7d:e5:52:63:52:56:0f:a3:9c:1c:49:92:1b:a9:6a: > f5:3d:0a:e0:73:8d:ed:89:4b:19:b9:ad:17:7d:ca:f3:bc:3e: > 6d:5f:7c:37:95:f2:50:2f:a2:ed:14:e4:eb:15:dd:7b:eb:93: > 0e:17:62:cb:14:6b:1c:41:6a:07:ba:9b:58:33:c0:5b:5d:32: > c3:f6:ad:c7:a7:42:b7:a2:6e:f0:fd:8c:94:d0:e4:87:bf:fa: > 9c:79:19:fd:54:d8:40:2a:71:6d:9b:f4:1f:42:78:fa:d1:5c: > ac:66:46:c6:2e:59:a3:b1:f1:42:3b:e8:91:6a:85:1d:eb:7d: > 12:da:0f:35:8f:99:50:13:fa:91:08:25:a9:83:f0:c2:a9:d3: > 71:f2:85:5f:3e:65:0e:93:ab:d0:39:89:49:b7:02:01:56:de: > e9:2d:4c:17:e4:58:a2:ea:b0:d0:66:74:a5:ac:91:2e:4f:e0: > 1f:bf:f8:b9:ac:99:32:17:94:9a:0a:ac:e6:78:d9:73:9a:01: > f2:1d:75:82 > > >> Jul 20 10:14:30 some.hostname.nl haproxy[452783]: x.x.x.x:54404 > >> [20/Jul/2023:10:14:30.375] cluster1-in/3: SSL handshake failure > >> (error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad > >> certificate) > >> > > > > This message could be a lot of things, a wrongly generated certificate, > > unsupported signature algorithms, incorrect chain... > > They are plain lets encrypt certificates created with acme.sh and with > ocsp must-staple enabled. Moreover, they work in 2.6.14. > > >> Downgrading to 2.6.14 fixes it again. > > > > I don't see why it would change like this, did you change the openssl > > version linked to haproxy? Recent distribution restrained some old > > algorithms and that could be a problem. We didn't changed much things > > in > > the loading between 2.6 and 2.8 so I'm not seeing why the behavior > > changed. > > The packages I use are the Debian 11 packages from Vincent Bernat. > Looking at the ldd output, nothing has changed. Also no libraries are > changed/upgraded when HAProxy is upgraded. > > > The best thing to do is to test with `openssl s_client -showcerts > > -connect some.hostname.nl:443` with both your versions to identify what > > changed. > > I've tested with 'openssl s_client -showcerts -connect mydomain.com:443 > -servername mydomain.com -status -tlsextdebug'' > > On 2.6.14 I get an OCSP response, on 2.8.1 I get: > > "OCSP response: no response sent" > > It really looks like HAProxy doesn't want to send the response coming > from the file. Is there any more information I can gather? > I'm CCing Remi which worked on this, something could have been broken when doing the ocsp-updater. -- William Lallemand
Re: Old style OCSP not working anymore?
On Thu, Jul 20, 2023 at 10:23:21AM +0200, Sander Klein wrote: > On 2023-07-19 11:00, William Lallemand wrote: > > On Mon, Jul 17, 2023 at 08:12:59PM +0200, Sander Klein wrote: > >> On 2023-07-17 15:17, William Lallemand wrote: > >> > On Thu, Jul 13, 2023 at 05:01:06PM +0200, Sander Klein wrote: > >> >> Hi, > >> >> > >> >> I tried upgrading from 2.6.14 to 2.8.1, but after the upgrade I > >> >> couldn't > >> >> connect to any of the sites behind it. > >> >> > >> >> While looking at the error it seems like OCSP is not working anymore. > >> >> Right now I have a setup in which I provision the certificates with > >> >> the > >> >> corresponding ocsp file next to it. If this not supported anymore? > >> > > >> > This is supposed to still be working, however we could have introduced > >> > bugs when building the ocsp-update. Are you seeing errors during the > >> > OCSP file loading? > >> > >> I don't see any errors, not even when I start haproxy by hand with > >> '-d'. > >> It's just like the ocsp isn't used at al. Also started haproxy with > >> strace attached and I see the ocsp files are loaded. > >> > >> Regards, > >> > >> Sander > >> > > > > Did you check with "show ssl ocsp-response" ? > > > > http://docs.haproxy.org/2.8/management.html#show%20ssl%20ocsp-response > > "show ssl ocsp-resonse" gives me a lot of output like: > > Certificate ID key : *LONGID* > Certificate path : /parth/to/cert.pem > Certificate ID: > Issuer Name Hash: *HASH* > Issuer Key Hash: *ANOTHERHASH* > Serial Number: *SERIAL* > You should check with the path argument so it gives you the date and status. > So I guess that's correct. But then I do a request for a site I get: > > Jul 20 10:14:30 some.hostname.nl haproxy[452783]: x.x.x.x:54404 > [20/Jul/2023:10:14:30.375] cluster1-in/3: SSL handshake failure > (error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad > certificate) > This message could be a lot of things, a wrongly generated certificate, unsupported signature algorithms, incorrect chain... > Downgrading to 2.6.14 fixes it again. I don't see why it would change like this, did you change the openssl version linked to haproxy? Recent distribution restrained some old algorithms and that could be a problem. We didn't changed much things in the loading between 2.6 and 2.8 so I'm not seeing why the behavior changed. The best thing to do is to test with `openssl s_client -showcerts -connect some.hostname.nl:443` with both your versions to identify what changed. -- William Lallemand
Re: Old style OCSP not working anymore?
On Mon, Jul 17, 2023 at 08:12:59PM +0200, Sander Klein wrote: > On 2023-07-17 15:17, William Lallemand wrote: > > On Thu, Jul 13, 2023 at 05:01:06PM +0200, Sander Klein wrote: > >> Hi, > >> > >> I tried upgrading from 2.6.14 to 2.8.1, but after the upgrade I > >> couldn't > >> connect to any of the sites behind it. > >> > >> While looking at the error it seems like OCSP is not working anymore. > >> Right now I have a setup in which I provision the certificates with > >> the > >> corresponding ocsp file next to it. If this not supported anymore? > > > > This is supposed to still be working, however we could have introduced > > bugs when building the ocsp-update. Are you seeing errors during the > > OCSP file loading? > > I don't see any errors, not even when I start haproxy by hand with '-d'. > It's just like the ocsp isn't used at al. Also started haproxy with > strace attached and I see the ocsp files are loaded. > > Regards, > > Sander > Did you check with "show ssl ocsp-response" ? http://docs.haproxy.org/2.8/management.html#show%20ssl%20ocsp-response -- William Lallemand
Re: [PATCH] BUILD: ssl: Build with new cryptographic library AWS-LC
On Tue, Jul 18, 2023 at 09:11:33AM +0200, Willy Tarreau wrote: > I'll let the SSL maintainers check all this, but my sentiment is that in > general if there are differences between the libs, it would be better if > we have a special define for this one as well. It's easier to write and > maintain "#if defined(OPENSSL_IS_BORINGSSL) || defined(OPENSSL_IS_AWSLC)" > than making it appear sometimes as one of them, sometimes as the other. > That's what we had a long time ago and it was a real pain, every single > move in any lib would cause breakage somewhere. Being able to reliably > identify a library and handle its special cases is much better. I agree, we could even add a build option OPENSSL_AWSLC=1 like we've done with wolfssl, since this is a variant of the Openssl API. Then every supported features could be activated with the HAVE_SSL_* defines in openssl-compat.h. Discovering the features with libreSSL and boringSSL version defines was a real mess, we are probably going to end up with a matrix of features supported by different libraries. I'm seeing multiple defines that can be useful in haproxy: - OPENSSL_IS_AWSLC could be used as Willy said, that could enough and we maybe won't need the build option. - OPENSSL_VERSION_NUMBER it seems to be set to 0x1010107f but is this 100% compatible with the openssl 1.1.1 API? - AWSLC_VERSION_NUMBER_STRING It seems to be the OPENSSL_VERSION_TEXT counterpart but I don't see the equivalent as a number, in OpenSSL there is OPENSSL_VERSION_NUMBER which is used for doing #if (OPENSSL_VERSION_NUMBER >= 0x1010107f) in the code for example, this is really important for maintenance if we want to support multiple versions of aws-lc. - AWSLC_API_VERSION maybe this would be enough instead of the VERSION_NUMBER. We could activate the HAVE_SSL_* defines using OPENSSL_VERSION_NUMBER and this. > > To Alex's concern on API compatibility: yes AWS-LC is aiming to provide a > > more stable API. We already run integration tests with 6 other projects [2] > > including HAProxy. This will help ensure API compatibility going forward. > > What is your specific concern with ABI compatibility? Are you looking to > > take > > the haproxy executable built with OpenSSL libcrypto/libssl and drop in > > AWS-LC > > without recompiling haproxy? Or do that between AWS-LC libcrypto/libssl > > versions? > > I personally have no interest in cross-libs ABI compatibility because > that does not make much sense, particularly when considering that Openssl > does not support QUIC so by definition there will be many symbol-level > differences. Regarding aws-lc's libs over time, yes for the users it > would be desirable that within a stable branch it's possible to update > the library or the application in any order without having to rebuild > the application. We all know that it's something that only becomes > possible once the lib stabilizes enough to avoid invasive backports in > stable branches. I don't know what the current status is for aws-lc's > stable branches at the moment. > Agreed, cross-libs ABI is not useful, but the ABI should remain stable between minor releases so the library package could be updated without rebuilding every software that depends on it. Regards, -- William Lallemand
Re: [PATCH] BUILD: ssl: Build with new cryptographic library AWS-LC
On Mon, Jul 17, 2023 at 05:56:15PM +0200, Илья Шипицин wrote: > also, if "aws-lc" is somewhat very similar to openssl-1.1.1, we do not > expect we'll catch a lot of build errors daily because we already run > builds against openssl-1.1.1, maybe weekly CI would be enough. a Weekly CI is good enough indeed, enough to monitor breakage and it won't disturb us during development. -- William Lallemand
Re: [PATCH 0/2] improve CI friendliness
On Sat, Jul 15, 2023 at 12:00:47AM +0200, Ilya Shipitsin wrote: > thanks to Andrew Hopkins from Amazon, we've learned that CI is already easy > to learn, > however few things can be improved. > > let us add naming convention inline comment, also if VTest fails, let is > highlight that. > > Ilya Shipitsin (2): > CI: add naming convention documentation > CI: explicitely highlight VTest result section if there's something > > .github/matrix.py | 18 +- > .github/workflows/vtest.yml | 1 + > 2 files changed, 14 insertions(+), 5 deletions(-) > > -- > 2.40.1 > > Merged, thank you! -- William Lallemand
Re: [PATCH 0/1] Implement new sample fetch method to get the curve name used in key agreement
On Mon, Jul 17, 2023 at 08:22:58AM -0500, Mariam John wrote: > This is an implementation of feature request > [#2165](https://github.com/haproxy/haproxy/issues/2165), > to get the EC curve name used during the key agreement in OpenSSL. This patch > includes the following > changes: > - new sample fetch methods `ssl_fc_curve` and `ssl_bc_curve`, to get the > curve name > - doc changes to add description for the new sample fetch methods > - a new regression test 'ssl_curve_name` to test the new sample fetch > methods. (Tested it with the > CI against my fork using github actions and it passes with all supported > SSL libraries and OpenSSL versions) > > This uses the function `SSL_get_negotiated_group` method available from the > OpenSSLv3 release. > > Thank you. > > Mariam John (1): > MEDIUM: ssl: new sample fetch method to get curve name > > doc/configuration.txt| 10 +++ > reg-tests/ssl/ssl_curve_name.vtc | 51 > src/ssl_sample.c | 46 > 3 files changed, 107 insertions(+) > create mode 100644 reg-tests/ssl/ssl_curve_name.vtc > Great, thank you! I just pushed your patch in the master branch. -- William Lallemand
Re: Wierd issue with OCSP updating
On Thu, Jul 13, 2023 at 07:10:29PM -0600, Shawn Heisey wrote: > On 7/13/23 15:00, Cyril Bonté wrote: > > Hi Shawn, > > > > Le 13/07/2023 à 18:48, Shawn Heisey a écrit : > >> Looks like on my last edit I deleted it and didn't add it to > >> defaults, so I was wrong in what I said. It throws a different error > >> when added to defaults: > >> Because it should be in the global section, not the defaults one ;) > > It didn't work in global either. It threw an error message that I did > not understand at first. > > After a little poking around with google, I added this section to the > config (with the ipv4 resolver setting in global) and that made it work: > > resolvers default > nameserver dns1 127.0.0.1:53 > nameserver dns2 8.8.8.8:53 > accepted_payload_size 8192 # allow larger DNS payloads > > Further investigation revealed that systemd-resolved was not setting > /etc/resolv.conf to the usual symlink. It was a real zero byte file. > > Fixing that so it is a symlink to > |/run/systemd/resolve/stub-resolv.conf|and commenting the new resolvers > section in haproxy.cfg has completely fixed the issue. > > I didn't think it was a bug in haproxy, but couldn't figure out why it > was misbehaving. Now I know it was a problem with /etc/resolv.conf. I > didn't think to look there because I could connect to things by name > from the shell prompt, so I assumed everything was good. > > Thanks, > Shawn Indeed, haproxy creates a 'default' resolvers section this way if you don't create one yourself: resolvers default parse-resolv-conf -- William Lallemand
Re: Wierd issue with OCSP updating
On Thu, Jul 13, 2023 at 10:48:41AM -0600, Shawn Heisey wrote: > On 7/12/23 04:13, Remi Tricot-Le Breton wrote: > > On 11/07/2023 22:22, Shawn Heisey wrote: > >> On 7/11/23 01:30, Remi Tricot-Le Breton wrote: > >> That directive didn't work in "global" but it was accepted when I > >> moved it to "defaults". But it didn't change the behavior. IPv6 is > >> completely disabled on the server. > > > > Didn't work as in an error was raised ? I have a local configuration > > file with this option in the global section and it seems to work fine. > > It failed the config check that is done by the systemd service before > restarting. It seems to indicate I am missing additional config that it > needs. > > elyograg@bilbo:~$ sudo haproxy -dD -c -f /etc/haproxy/haproxy.cfg > [NOTICE] (521767) : haproxy version is 2.8.1 > [NOTICE] (521767) : path to executable is /usr/local/sbin/haproxy > [ALERT](521767) : config : Proxy '': Can't find > resolvers section 'default' for do-resolve action. > [ALERT](521767) : config : Proxy '': Can't find > resolvers section 'default' for do-resolve action. > [DIAG] (521767) : config : Generating a random cluster secret. You > should define your own one in the configuration to ensure consistency > after reload/restart or across your whole cluster. > [ALERT](521767) : config : Fatal errors found in configuration. > Hm we should probably improve the errors here, it seems to happen because you set an httpclient option in your global section but your /etc/resolv.conf wasn't available. I'll definitively try to improve this. > > You can use the "httpclient" CLI command this way: > > echo "expert-mode on; httpclient GET > > http://r3.o.lencr.org/MFMwUTBPME0wSzAJBgUrDgMCGgUABBRI2smg%2ByvTLU%2Fw3mjS9We3NfmzxAQUFC6zF7dYVsuuUAlA5h%2BvnYsUwsYCEgOq9K0xVAXkgj8X4cNGeMutQw%3D%3D; > > | socat - > > I get an error from that, and it makes no sense to me. > > > elyograg@bilbo:~$ echo "expert-mode on; httpclient GET > http://r3.o.lencr.org/MFMwUTBPME0wSzAJBgUrDgMCGgUABBRI2smg%2ByvTLU%2Fw3mjS9We3NfmzxAQUFC6zF7dYVsuuUAlA5h%2BvnYsUwsYCEgOq9K0xVAXkgj8X4cNGeMutQw%3D%3D; > > | sudo socat /etc/haproxy/stats.socket - > Permission denied > > This command is restricted to expert mode only. > > It happens because you don't have the right level on your stats socket, expert-mode needs an admin level. -- William Lallemand
Re: Old style OCSP not working anymore?
On Thu, Jul 13, 2023 at 05:01:06PM +0200, Sander Klein wrote: > Hi, > > I tried upgrading from 2.6.14 to 2.8.1, but after the upgrade I couldn't > connect to any of the sites behind it. > > While looking at the error it seems like OCSP is not working anymore. > Right now I have a setup in which I provision the certificates with the > corresponding ocsp file next to it. If this not supported anymore? > > Regards, > > Sander > This is supposed to still be working, however we could have introduced bugs when building the ocsp-update. Are you seeing errors during the OCSP file loading? -- William Lallemand
Re: Compiling HAProxy 2.8.1 with WolfSSL 5.6.3 yields errors about OCSP
On Fri, Jul 14, 2023 at 11:01:16PM +0200, Marcel Menzel wrote: > Hello List, > > Trying to compile HAProxy version 2.8.1 with WolfSSL 5.6.3 results in > the following error: > > src/ssl_sock.c: In function ‘ssl_sock_load_ocsp’: > src/ssl_sock.c:1117:9: error: unknown type name ‘tlsextStatusCb’ > 1117 | tlsextStatusCb callback; > | ^~ > make: *** [Makefile:998: src/ssl_sock.o] Error 1 > make: *** Waiting for unfinished jobs > > In my makefile / Arch Linux PKGBUILD I have the following: > > unset CFLAGS > unset CXXFLAGS > unset LDFLAGS > > export CFLAGS="$CFLAGS -fwrapv" > > make \ > CFLAGS="$CFLAGS" \ > LDFLAGS="$LDFLAGS" \ > CPU=generic \ > TARGET=linux-glibc \ > USE_GETADDRINFO=1 \ > USE_LUA=1 \ > USE_OPENSSL_WOLFSSL=1 \ > USE_PCRE2=1 USE_PCRE2_JIT=1 \ > USE_PROMEX=1 \ > USE_SYSTEMD=1 \ > USE_ZLIB=1 > > Using Kernel 6.1.38-hardened1 if of interest. Am I missing something here? > > > - Marcel Hello, WolfSSL 5.6.3 and HAProxy 2.8.1 are compatible with each other, however you need to compile wolfssl and haproxy the right way. You should probably try building haproxy without reseting "LDFLAGS" and "CFLAGS" first, and then add "SSL_LIB" and "SSL_INC" with the right wolfssl path. Please follow the build instruction in the INSTALL file, there are also instructions regarding how to build WolfSSL with haproxy compatibility. Regards, -- William Lallemand
Re: [PATCH] BUILD: ssl: Build with new cryptographic library AWS-LC
On Wed, Jul 12, 2023 at 12:26:06AM +, Hopkins, Andrew wrote: > Hello HAProxy maintainers, I work on the AWS libcrypto (AWS-LC) > project [1]. Our goal is to improve the cryptography we use internally > at AWS and help our customers externally. In the spirit of helping > people use good crypto we know it’s important to make it easy to use > AWS-LC everywhere they use cryptography. This is why we are interested > in integrating AWS-LC into HAProxy. > > AWS-LC is a fork of BoringSSL which you already partially support. We > recently merged in several PRs (Full OCSP support [2] and custom > extension support [3]) to fully support HAProxy the same as OpenSSL. > To ensure we continue to support HAProxy long term we added HAProxy > built with AWS-LC to our CI [4]. > > In our early testing we see modest improvements in overall throughput > when compared to OpenSSL 3.1 on x86 and arm CPUs. Following a similar > setup as this blog [5] I observe a small (~2.5%) increase in requests > per second for 5 kb requests on a C6i (x86) and C6g (arm) instance > using TLS 1.3 and AES 256 GCM. For both tests I used `taskset -c 2-47 > ./h1load -e -ll -P -t 46 -s 30 -d 120 -c 500 https://[c6i or c6g > ip]:[aws-lc or openssl port]/?s=5k`. > > This small difference in this symmetric crypto workload comes down to > AWS-LC and OpenSSL having similar AES implementations. We observe > larger performance improvements with our micro-benchmarks for > algorithms related to the TLS handshake such as 15% reduction for ECDH > with P-256, and 40% reduction for P-521 on a C6i. This comes from our > s2n-bignum library[6], a formally verified bignum library with a focus > on performance and correctness. > > When built with AWS-LC all current regression tests pass. I have > included a small patch to update your documentation with AWS-LC as an > option and I attempted to add AWS-LC to your CI. I need a little help > figuring out how to test that part. Lastly from your excellent > contributing guide I am not subscribed so I would like to be cc’d on > all responses. > > Thanks, Andrew > Hello Andrew, That's interesting and we are open to new libraries that can give us a good alternative to OpenSSL. However the CI is becoming quite slow and we'd rather not add a new build for each push. I don't really like the fact that the patch is based on the git master for the push, the CI principally used to check if we didn't break anything in haproxy, so if the library keep changing during haproxy development it's more difficult to know if a breakage is because of haproxy or because of the library. We stopped building BoringSSL on the CI because of this, because there wasn't any clear maintainenance cycle and the library kept changing. It looks like you have real releases in awc-ls though. What I suggest is that we create a scheduled build for aws-lc like we've done with https://github.com/haproxy/haproxy/blob/master/.github/workflows/openssl-nodeprecated.yml for example. This way we don't increase the CI build for each push, and using the master branch don't become a problem. Regards, -- William Lallemand
Re: [PATCH 0/1] Implement new sample fetch method to get the curve name used in key agreement
On Fri, Jul 14, 2023 at 02:59:52AM -0500, Mariam John wrote: > This is an implementation of feature request > [#2165](https://github.com/haproxy/haproxy/issues/2165), > to get the EC curve name used during the key agreement in OpenSSL. This patch > includes the following > changes: > - new sample fetch methods `ssl_fc_curve` and `ssl_bc_curve`, to get the > curve name > - doc changes to add description for the new sample fetch methods > - updates the existing regression tests to test the new sample fetch methods > > This uses the function `SSL_get_negotiated_group` method available from the > OpenSSLv3 release. > > Thank you. > > Mariam John (1): > MEDIUM: ssl: new sample fetch method to get curve name > > doc/configuration.txt| 8 + > reg-tests/ssl/ssl_client_samples.vtc | 2 ++ > reg-tests/ssl/ssl_curves.vtc | 4 +++ > src/ssl_sample.c | 46 > 4 files changed, 60 insertions(+) > Hello Mariam, It seems like you sent us the previous patch by mistake? I pushed the patch in a separate branch to run the CI on it: https://github.com/haproxy/haproxy/actions/runs/5573879545/jobs/10181759082 Regards, -- William Lallemand
Re: [PATCH 0/1] Implement new sample fetch method to get the curve name used in key agreement
bind "${tmpdir}/ssl-ecdhe-256.sock" ssl crt ${testdir}/common.pem
> ca-file ${testdir}/set_cafile_rootCA.crt verify optional ecdhe prime256v1
> server s1 ${s1_addr}:${s1_port}
> +http-response add-header x-ssl-fc-curve-name %[ssl_fc_curve]
>
> } -start
>
> @@ -105,6 +107,7 @@ client c1 -connect ${h1_clearlst_sock} {
>txreq
>rxresp
>expect resp.status == 200
> + expect resp.http.x-ssl-fc-curve-name == "prime256v1"
> } -run
>
> # The backend tries to use the prime256v1 curve that is not accepted by the
> @@ -129,6 +132,7 @@ client c4 -connect ${h1_clearlst_sock} {
>txreq -url "/ecdhe-256"
>rxresp
>expect resp.status == 200
> + expect resp.http.x-ssl-fc-curve-name == "prime256v1"
> } -run
>
Be careful with the tests, they should pass with all supported
SSL libraries, which is quite difficult to do.
I pushed your patch in this branch so you could check the CI:
https://github.com/haproxy/haproxy/tree/feat-2165
I recommend you to run your own CI on a github fork, just activate
github action on your fork so all the reg-tests
are run with openssl 1.0.2, 1.1.1, 3.0, 3.1, libreSSL and quicTLS, doing
it manually is quite difficult.
You can create a new .vtc file for your test, and sets a required SSL
version in its header, we can't disable part of the tests in the .vtc
depending on the openssl version unfortunately.
Also, try to check the other ssl_bc_curves sample fetch in your test.
Don't hesitate to ask if you have difficulties with this part, it can be
bothersome.
> syslog Slg_cust_fmt -wait
> diff --git a/src/ssl_sample.c b/src/ssl_sample.c
> index 5aec97fef..d7a7a09f9 100644
> --- a/src/ssl_sample.c
> +++ b/src/ssl_sample.c
> @@ -1304,6 +1304,46 @@ smp_fetch_ssl_fc_is_resumed(const struct arg *args,
> struct sample *smp, const ch
> return 1;
> }
>
> +/*
> + * string, returns the EC curve used for key agreement on the
> + * front and backend connection.
> + *
> + * The function to get the curve name (SSL_get_negotiated_group) is only
> available
> + * in OpenSSLv3 onwards and not for previous versions.
> + */
> +#if (HA_OPENSSL_VERSION_NUMBER >= 0x300fL)
> +static int
> +smp_fetch_ssl_fc_ec(const struct arg *args, struct sample *smp, const char
> *kw, void *private)
> +{
> +struct connection *conn;
> +SSL *ssl;
> +int nid;
> +
> +if (obj_type(smp->sess->origin) == OBJ_TYPE_CHECK)
> +conn = (kw[4] == 'b') ? sc_conn(__objt_check(smp->sess->origin)->sc)
> : NULL;
> +else
> +conn = (kw[4] != 'b') ? objt_conn(smp->sess->origin) :
> +smp->strm ? sc_conn(smp->strm->scb) : NULL;
> +
> +ssl = ssl_sock_get_ssl_object(conn);
> +if (!ssl)
> +return 0;
> +
> +nid = SSL_get_negotiated_group(ssl);
> +if (!nid)
> +return 0;
> +smp->data.u.str.area = (char *)OBJ_nid2sn(nid);
> +if (!smp->data.u.str.area)
> +return 0;
> +
> +smp->data.type = SMP_T_STR;
> +smp->flags |= SMP_F_VOL_SESS | SMP_F_CONST;
> +smp->data.u.str.data = strlen(smp->data.u.str.area);
> +
> +return 1;
> +}
> +#endif
The code looks good to me, only the reg-tests part should be reworked IMO.
Regards,
--
William Lallemand
Re: OCSP renewal with 2.8
Hello, On Sat, Jun 03, 2023 at 04:28:30PM -0600, Shawn Heisey wrote: > On 6/3/23 15:37, Shawn Heisey wrote: > > On 6/3/23 15:28, Shawn Heisey wrote: > >> So maybe a completely separate global option makes sense. The > >> crt-list requirement is not really a burden for me, but for someone > >> who uses a LOT of certificates that change frequently, it probably > >> would become a burden. > > > > Unless it is possible to have a directory as an entry in the crt-list > > file like it is for the crt option. The crt-list doc does not say that > > this is possible, and I have not tested it. > > Using a directory as an entry in the crt-list file causes `haproxy -c > -f` to hang. Which I think means that crt-list doesn't support directories. > Hm that's weird, that shouldn't load at all! I'll take a look. > How hard would it be to add that support? I would hope that most of the > code needed is already present in the part that parses crt options. > We won't support this, directories are represented internally as a crt-list, this would add a huge complexity in the code. crt-list were made as an cleaner alternative to directories so you could specify each file you need manually and set options to them. As I explained in my previous mail, the option was not set on the bind lines because of architectural problems, but you could expect to have a way to do it globally in future versions. -- William Lallemand
Re: OCSP renewal with 2.8
> On 2023-06-02 (Fr.) 22:42, Lukas Tribus wrote: > > I suggest we make it configurable on the bind line like other ssl > > options, so it will work for the common use cases that don't involve > > crt-lists, like a simple crt statement pointing to a certificate or a > > directory. > > That's what we've done in the first place, but I decided to remove it because I was not happy with the architecture. And once you have something like this, you have to keep the configuration compatibility for the next versions and then you are stuck with something awful. My concern here, is that the ocsp-update option was never a "bind" option, it's a feature which applies on the internal storage part, which is not directly exposed in the configuration. So for example if you use the same certificate on multiple bind lines, setting "ocsp-update on" on one line and "ocsp-update off" on the other doesn't make sense. It is the same problem we have with the "key" option, which applies on the storage. We are well aware on the current limitations of this model, and we are working on it, that's why it landed in the crt-list for now, but that will evolve! > > It could also be a global option *as well*, but imho it does need to > > be a bind line configuration option, just like strict-sni, alpn and > > ciphers, so we can enable it specifically (per frontend, per bind > > line) without requiring crt-list. Sure, that what considered for the evolution of the feature ! -- William Lallemand
Re: OCSP renewal with 2.8
On Fri, Jun 02, 2023 at 09:55:25PM +0200, Willy Tarreau wrote: > On Fri, Jun 02, 2023 at 01:29:31PM +0300, Matthias Fechner wrote: > > Am 02.06.2023 um 04:13 schrieb Shawn Heisey: > > > @Matthias I have no idea whether crt-list can load all certs in a > > > directory like crt can. If it can't, then you will probably need a > > > script for starting/restarting haproxy that generates the cert list > > > file. If you wantthat script to be automatically run whenever someone > > > does `systemctl restart haproxy`, you could use the ExecStartPre and > > > ExecReloadPre options in a systemd service file to run your script. > > > > > > My certificate files contain the server cert, the issuer cert, the > > > private key, and DH PARAMETERS that are unique to that cert. > > > > maybe adding a global configuration parameter to enable ocsp retrieval for > > all certificates? > > Initially during the design phase we thought about having 3 states: > "off", "on", "auto", with the last one only enabling updates for certs > that already had a .ocsp file. But along discussions with some users > we were told that it was not going to be that convenient (I don't > remember why, but I think that Rémi and/or William probably remember > the reason), and it ended up dropping "auto". > Because at the time it was an option not to activate the ocsp-update, but to activate the ocsp, so it could be activated by letting a .ocsp file, or by doing it automatically by retrieving it, but that was super confusing so we decided to just have an on/off option to activate it. > Alternately maybe instead of enabling for all certs, what would be > useful would be to just change the default, because if you have 100k > certs, it's likely that 99.9k work one way and the other ones the other > way, and what you want is to indicate the default and only mention the > exception for those concerned. Indeed that could be a way to do it. -- William Lallemand
Re: OCSP renewal with 2.8
On Thu, Jun 01, 2023 at 11:42:34PM +0200, Willy Tarreau wrote: > So this means that the doc is still not clear enough and we need to > improve this. And indeed, I'm myself confused because William told me > a few days ago that "ocsp-update" was for crt-list lines only and it's > found in the "bind line options" section. And of course, when there are > examples, they're not the ones you're looking for, that's classical! Yep, that's exactly what I said to you, that it's in the documentation of the bind lines because we don't have specific crt-list documentation, and it's specified in the documentation that it's only for crt-list. -- William Lallemand
Re: @Wolfssl: any plans to add "ECH (Encrypted client hello) support" and question about Roadmap
On Thu, Jun 01, 2023 at 02:15:57PM +0200, Aleksandar Lazic wrote: > Hi, > > As we have now a shiny new LTS let's take a look into the future :-) > > As the Wolfssl looks like a good future alternative for OpenSSL is there > any plan to add ECH (Encrypted client hello) ( > https://github.com/haproxy/haproxy/issues/1924 ) into Wolfssl? > > Is there any Idea which feature is planed to be added by HAProxy Company > from the feature requests > https://github.com/haproxy/haproxy/labels/type%3A%20feature ? > > Regards > Alex > As far as I know ECH is still a draft and was not release yet, it looks like it was already integrated in wolfssl though: https://www.wolfssl.com/encrypted-client-hello-ech-now-supported-wolfssl/ But since the RFC is not released yet their implementation would probably change. But this won't probably not be usable for HAProxy since we are using the OpenSSL compatiblity layer. If you want to discuss this, please continue on the haproxy github ticket or we will again split the discussion between multiple support.. -- William Lallemand
Re: [PATCH] CI: monthly Fedora Rawhide, bump "actions/checkout" to v3
On Sat, Apr 08, 2023 at 01:36:48PM +0200, Илья Шипицин wrote: > Hello, > > couple of patches: > > 1) Fedora Rawhide (known to include the most recent compilers) monthly > builds > 2) small cleanup, "actions/checkout" bumped to v3 > > Cheers, > Ilya Thanks, merged. -- William Lallemand
Re: [ANNOUNCE] haproxy-2.8-dev7
On Sat, Apr 08, 2023 at 06:30:24PM +0200, Willy Tarreau wrote: > - William managed to improve acme.sh to directly manage haproxy at > runtime via the CLI, and to start a config without certificates. > This means that once his pull request will be merged, Let's Encrypt > support will be totally seamless. In case it wouldn't be merged (there > are many PRs pending there), we'd find a different way to host this > change, either by integrating it as a "plugin" with haproxy, or by > forking the repository and providing it under the haproxy github > organization. More info in the PR here: > https://github.com/acmesh-official/acme.sh/pull/4581 > Regarding this, I also updated the documentation of the stateless mode so people can easily configure haproxy for it, no more proxying is required: https://github.com/acmesh-official/acme.sh/wiki/Stateless-Mode#haproxy -- William Lallemand
Re: [PATCH] BUG/MINOR: ssl: Stop leaking `err` in ssl_sock_load_ocsp()
On Mon, Mar 27, 2023 at 03:43:22PM +0200, Remi Tricot-Le Breton wrote: > > On 27/03/2023 15:31, Tim Düsterhus wrote: > > Hi > > > > On 3/19/23 16:07, Tim Duesterhus wrote: > >> Previously performing a config check of `.github/h2spec.config` would > >> report a > >> 20 byte leak as reported in GitHub Issue #2082. > >> > >> The leak was introduced in a6c0a59e9af65180c3ff591b91855bea8d19b352, > >> which is > >> dev only. No backport needed. > > > > I believe you might've missed this patch. > > > > Best regards > > Tim Düsterhus > > Hi Tim, > > Sorry about that delay. The patch looks good to me. I'll let William > merge it when he has the time. > > Rémi > Thanks to both of you, merged. -- William Lallemand
Re: [PATCH 0/5] Changes to matrix.py
On Thu, Dec 29, 2022 at 06:24:52PM +0100, Willy Tarreau wrote: > On Thu, Dec 29, 2022 at 11:15:30PM +0600, ??? wrote: > > I'm fine with reformatting/caching/whatever. > > > > btw, Tim, while on this, can you please add LibreSSL-3.7.0 (fixed) to > > stable branches ? > > I've forgotten, now we do not run libressl for stable branches at all > > Thank you both for the patch and the review. If you don't mind I'll wait > until early next week for William to have a look, as he often looks > deeper into the CI stuff and has stronger expectations than me. But > generally speaking I agree that it looks more readable after the change. > > thanks, > Willy > LGTM. -- William Lallemand
Re: Failures on "Generate Build Matrix"
On Fri, Dec 23, 2022 at 12:14:15AM +0600, Илья Шипицин wrote: > haproxy/vtest.yml at master · chipitsine/haproxy (github.com) > <https://github.com/chipitsine/haproxy/blob/master/.github/workflows/vtest.yml#L28-L29> > > secret name can be arbitrary, for example "TOKEN". > env variable is GITHUB_API_TOKEN > I passed some time doing tests and reading the github configuration, in fact we don't need to generate a token ourselves and to add it to the secret configuration. Github has a GITHUB_TOKEN which is generated at the beginning of the job and destroyed at the end, so I just add it in the environment as recommended in the documentation. https://docs.github.com/en/actions/security-guides/automatic-token-authentication#about-the-github_token-secret So we can remove any token that was generated for this problem, it is not useful. Regards, -- William Lallemand
Re: Failures on "Generate Build Matrix"
On Thu, Dec 22, 2022 at 06:12:46PM +0100, Willy Tarreau wrote: > On Thu, Dec 22, 2022 at 11:00:26PM +0600, ??? wrote: > > I'm not sure if it possible to issue organization based token (not a > > personal one). > > > > As for visibility, secrets are not visible for pull requests. > > My concern is not that they are in PR or any such thing, but they're > passed in HTTP requests and function arguments in python scripts. So > once we get a failure, if the failed request is dumped into the CI's > logs, or if the python interpreter emits a stack trace with all > arguments to the functions in the stack, the build logs will reveal > the secret. Maybe there's a way to be certain that the logs from the > python script are never dumped to publicly accessible logs, or to > redirect them to files only accessible to authorized people, and that > would be fine, but until this, I don't know what such guarantees we > have. This is my concern regarding the use of this token like this. > > Thanks, > Willy You need to be logged to see the logs of the CI, I don't know if it is only accessible to the people in the haproxy group or if it only need to be logged to github. -- William Lallemand
Re: Failures on "Generate Build Matrix"
On Thu, Dec 22, 2022 at 05:37:59PM +0100, William Lallemand wrote: > On Thu, Dec 22, 2022 at 10:32:22PM +0600, Илья Шипицин wrote: > > I attached a patch. It keeps current behaviour and is safe to apply. > > > > in order to make a difference, github token must be issued and set via > > github ci settings. > > > > Ilya > > > > I just pushed it, thank you. > I'm kind of confused, where is the token supposed to be created? I'm only seeing the "personal access tokens". Thanks. -- William Lallemand
Re: Failures on "Generate Build Matrix"
On Thu, Dec 22, 2022 at 10:32:22PM +0600, Илья Шипицин wrote: > I attached a patch. It keeps current behaviour and is safe to apply. > > in order to make a difference, github token must be issued and set via > github ci settings. > > Ilya > I just pushed it, thank you. -- William Lallemand
Failures on "Generate Build Matrix"
Hi Guys,
Since a few days I'm seeing some failure on the "Generate Build Matrix" part of
the CI, the request.urlopen() seems to fail the urlopen(), it's easy to restart
it manually but it happened to me a few times recently.
Do you think that would be possible to cache these values so the script don't
fail ? or maybe just let the "latest" fail.
Generating matrix for type 'master'.
Traceback (most recent call last):
File "/home/runner/work/haproxy/haproxy/.github/matrix.py", line 167, in
ssl = determine_latest_openssl(ssl)
File "/home/runner/work/haproxy/haproxy/.github/matrix.py", line 29, in
determine_latest_openssl
openssl_tags =
urllib.request.urlopen("https://api.github.com/repos/openssl/openssl/tags;)
File "/usr/lib/python3.10/urllib/request.py", line 216, in urlopen
return opener.open(url, data, timeout)
File "/usr/lib/python3.10/urllib/request.py", line 525, in open
response = meth(req, response)
File "/usr/lib/python3.10/urllib/request.py", line 634, in http_response
response = self.parent.error(
File "/usr/lib/python3.10/urllib/request.py", line 563, in error
return self._call_chain(*args)
File "/usr/lib/python3.10/urllib/request.py", line 496, in _call_chain
result = func(*args)
File "/usr/lib/python3.10/urllib/request.py", line 643, in http_error_default
raise HTTPError(req.full_url, code, msg, hdrs, fp)
urllib.error.HTTPError: HTTP Error 403: rate limit exceeded
Thanks!
--
William Lallemand
[ANNOUNCE] haproxy-2.7.1
UNIX socket Cedric Paillet (2): BUG/MINOR: promex: create haproxy_backend_agg_server_status MINOR: promex: introduce haproxy_backend_agg_check_status Christopher Faulet (10): BUG/MEDIIM: stconn: Flush output data before forwarding close to write side DOC: promex: Add missing backend metrics REGTESTS: fix the race conditions in iff.vtc BUG/MEDIUM: freq-ctr: Don't compute overshoot value for empty counters BUG/MEDIUM: resolvers: Use tick_first() to update the resolvers task timeout BUG/MEDIUM: mux-h1: Don't release H1 stream upgraded from TCP on error BUG/MINOR: mux-h1: Fix test instead a BUG_ON() in h1_send_error() BUG/MINOR: mux-h1: Report EOS on parsing/internal error for not running stream BUG/MINOR:: mux-h1: Never handle error at mux level for running connection BUG/MEDIUM: stats: Rely on a local trash buffer to dump the stats Ilya Shipitsin (3): CI: github: split ssl lib selection based on git branch CI: github: remove redundant ASAN loop CI: github: split matrix for development and stable branches Remi Tricot-Le Breton (1): BUG/MINOR: ssl: Fix memory leak of find_chain in ssl_sock_load_cert_chain William Lallemand (16): BUG/MINOR: ssl: initialize SSL error before parsing BUG/MINOR: ssl: initialize WolfSSL before parsing CI: github: reintroduce openssl 1.1.1 MINOR: mworker: display an alert upon a wait-mode exit BUG/MEDIUM: mworker: fix segv in early failure of mworker mode with peers BUG/MEDIUM: mworker: create the mcli_reload socketpairs in case of upgrade BUG/MEDIUM: httpclient/lua: double LIST_DELETE on end of lua task REGTESTS: startup: check maxconn computation BUG/MINOR: startup: don't use internal proxies to compute the maxconn REGTESTS: startup: change the expected maxconn to 11000 CI: github: set ulimit -n to a greater value REGTESTS: startup: activate automatic_maxconn.vtc CLEANUP: ssl: remove check on srv->proxy REGTESTS: startup: add alternatives values in automatic_maxconn.vtc BUILD: peers: peers-t.h depends on stick-table-t.h REGTESTS: startup: disable automatic_maxconn.vtc Willy Tarreau (13): BUG/MEDIUM: checks: do not reschedule a possibly running task on state change BUG/MINOR: checks: make sure fastinter is used even on forced transitions BUG/MINOR: init/threads: continue to limit default thread count to max per group BUILD: atomic: atomic.h may need compiler.h on ARMv8.2-a BUILD: makefile/da: also clean Os/ in Device Atlas dummy lib dir CLEANUP: pools: move the write before free to the uaf-only function CLEANUP: pool: only include pool-os from pool.c not pool.h REORG: pool: move all the OS specific code to pool-os.h CLEANUP: pools: get rid of CONFIG_HAP_POOLS DEBUG: pool: show a few examples in -dMhelp MINOR: pools: make DEBUG_UAF a runtime setting MINOR: debug: support pool filtering on "debug dev memstats" MINOR: debug: add a balance of alloc - free at the end of the memstats dump Youfu Zhang (1): BUG/MAJOR: fcgi: Fix uninitialized reserved bytes scientiamobile (1): LICENSE: wurfl: clarify the dummy library license. --- -- William Lallemand
Re: Reproducible CI build with OpenSSL and "latest" keyword
On Wed, Dec 14, 2022 at 06:34:26PM +0500, Илья Шипицин wrote: > I am attaching another patch, i.e. using "ubuntu-latest" and "macos-latest" > for development branches and fixed images for stable branches. > Thank you, that make sense, I'll backport it to 2.6 as well. We just need to be careful every 2 years when the ubuntu version change and an HAProxy release is done, not to be stuck in 22.04 :-) -- William Lallemand
Re: Reproducible CI build with OpenSSL and "latest" keyword
On Mon, Dec 12, 2022 at 07:27:59PM +0500, Илья Шипицин wrote: > I attached a patch. > Thanks! > btw, we only build for the latest LibreSSL. are we ok to skip LibreSSL for > stable branches ? > In <= 2.5 we are still building with 3.5.3, http://git.haproxy.org/?p=haproxy-2.5.git;a=blob;f=.github/matrix.py;hb=HEAD#l132 Ideally it would be better to still build libreSSL in stable. In my opinion there should be at least one version + the latest for this method to work, but if the latest is equal to an already built version that doesn't make sens to build it again. -- William Lallemand
Re: Reproducible CI build with OpenSSL and "latest" keyword
On Mon, Dec 12, 2022 at 08:48:06AM +0100, William Lallemand wrote: > Hi Ilya ! > > On Mon, Dec 12, 2022 at 10:56:11AM +0500, Илья Шипицин wrote: > > hello, > > > > I made some prototype of I meant: > > > > https://github.com/chipitsine/haproxy/commit/c95955ecfd1a5b514c235b0f155bfa71178b51d5 > > > > - We don't often use "dev" in our branches so we should build everything > when it's not a stable branch. > > - We don't want to build "3.0" OR latest, in fact we only need to > condition the "latest" build, because the other one will always be > built. > > So once the "3.1" is released we could add an entry for it to > the file and "latest" will be another version. This way we could > backport the "3.1" in previous branches if we want to support it. > > > I;m not sure how stable branches are named in private github ci. If you can > > enlighten me, I'll try to adopt. > > currently, I did the following, if branch name is either master or contains > > "dev", so "latest" semantic is chosen, fixed versions are used otherwise. > > > > The stable branches are named "haproxy-X.Y", so in my opinion we should > build the "latest" for anything which is not a stable branch. > > > also, I know that the same ci is used for > > > > https://github.com/haproxytech/quic-dev > > > > > > @Frederic Lecaille , which behaviour would you like > > for that repo ? what is branch naming convention ? > > > The same as the master branch IMHO. > > Also, the problem is uglier than I thought, we are not testing 1.1.1 > anymore since "ubuntu-latest" was upgraded to 22.04 a few weeks ago > without us noticing. "ssl=stock" is now a 3.0 branch. It brokes all > stable branches below 2.6 because they need the deprecated SSL API. > I changed "ubuntu-latest" to "ubuntu-20.04" for those branches so it > works as earlier. I'm going to reintroduce "1.1.1" for master to 2.6 so > it is correctly tested again. > > In my opinion we need a similar mecanism for the distribution than for > the ssl libs. Maybe using "latest" only in dev branches and a fixed > version for stable branches will be enough. > > Regards, > Just thought about something, is it possible to have the versions in the job names ? So we don't have surprises. For example the Ubuntu version which was resolved by "ubuntu-latest" and the SSL version of "ssl=stock", we could easily see the changes this way. -- William Lallemand
Re: [PATCH] CI: Add `schedule` to vtest.yml
On Tue, Dec 06, 2022 at 11:35:03PM +0100, Tim Duesterhus wrote:
> William,
>
> On 12/6/22 19:40, William Lallemand wrote:
> > I disagree, porting to a new API is not something you would do just
> > before a release, you need to do it progressively if possible, because
> > it could introduce heavy development and sometimes discussions with the
> > library developers and unfortunately that could take time.
>
> I understand now. I thought this was primarily about bumping new patch
> versions, not about testing new feature branches.
>
> Please find a patch attached that will start to run the vtest.yml workflow
> weekly early on Thursday morning, making the results available at the start
> of the Thursday workday.
>
> If that change is working correctly, we should see that the "Generate Build
> Matrix" step outputs "Generating matrix for type 'schedule'." for those
> scheduled jobs. You can then add whatever extra jobs you desire to matrix.py
> by checking for `build_type == "schedule"`, like this:
>
> ssl_versions = [
> "stock",
> "OPENSSL_VERSION=1.0.2u",
> "OPENSSL_VERSION=3.0.0",
> ]
>
> if build_type == "schedule":
> ssl_versions.append("OPENSSL_VERSION=latest")
>
> Best regards
> Tim Düsterhus
>
> Apply with `git am --scissors` to automatically cut the commit message.
>
> -- >8 --
> This will run the vtest.yml workflow weekly on every Thursday morning in
> addition to running on every push.
>
> As the `github.event_name` is passed as a parameter to `matrix.py`, this
> allows
> to run specific jobs (e.g. heavy jobs or unstable ones) only on schedule if
> the
> need arises.
> ---
> .github/workflows/vtest.yml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/.github/workflows/vtest.yml b/.github/workflows/vtest.yml
> index fb7b1d968a..65892cf6b8 100644
> --- a/.github/workflows/vtest.yml
> +++ b/.github/workflows/vtest.yml
> @@ -10,6 +10,8 @@ name: VTest
>
> on:
>push:
> + schedule:
> + - cron: "37 5 * * 4" # 05:37 UTC on Thursday
>
> permissions:
>contents: read
After discussing with the team it seems like we won't do it this way,
and will only need to condition the "latest" build in the dev branches
in the current CI.
But that's good to know it's doable if we change our mind.
Thanks Tim!
--
William Lallemand
Re: Reproducible CI build with OpenSSL and "latest" keyword
Hi Ilya ! On Mon, Dec 12, 2022 at 10:56:11AM +0500, Илья Шипицин wrote: > hello, > > I made some prototype of I meant: > > https://github.com/chipitsine/haproxy/commit/c95955ecfd1a5b514c235b0f155bfa71178b51d5 > - We don't often use "dev" in our branches so we should build everything when it's not a stable branch. - We don't want to build "3.0" OR latest, in fact we only need to condition the "latest" build, because the other one will always be built. So once the "3.1" is released we could add an entry for it to the file and "latest" will be another version. This way we could backport the "3.1" in previous branches if we want to support it. > I;m not sure how stable branches are named in private github ci. If you can > enlighten me, I'll try to adopt. > currently, I did the following, if branch name is either master or contains > "dev", so "latest" semantic is chosen, fixed versions are used otherwise. > The stable branches are named "haproxy-X.Y", so in my opinion we should build the "latest" for anything which is not a stable branch. > also, I know that the same ci is used for > > https://github.com/haproxytech/quic-dev > > > @Frederic Lecaille , which behaviour would you like > for that repo ? what is branch naming convention ? > The same as the master branch IMHO. Also, the problem is uglier than I thought, we are not testing 1.1.1 anymore since "ubuntu-latest" was upgraded to 22.04 a few weeks ago without us noticing. "ssl=stock" is now a 3.0 branch. It brokes all stable branches below 2.6 because they need the deprecated SSL API. I changed "ubuntu-latest" to "ubuntu-20.04" for those branches so it works as earlier. I'm going to reintroduce "1.1.1" for master to 2.6 so it is correctly tested again. In my opinion we need a similar mecanism for the distribution than for the ssl libs. Maybe using "latest" only in dev branches and a fixed version for stable branches will be enough. Regards, -- William Lallemand
Re: Reproducible CI build with OpenSSL and "latest" keyword
Tim, On Tue, Dec 06, 2022 at 06:59:30PM +0100, Tim Düsterhus wrote: > > What I suggest is to stop using "latest" for the "git push" CI, but > > using it only in a separate CI (once a day/week I don't know). And only > > use fixed version of the libraries on the CI so builds are not broken by > > external components. Because in my opinion the "git push" CI is to test > > our code, not the libraries. > > > > I don't even think such a weekly job is necessary [1]. > Add an item to the release checklist "check if any new SSL versions > are available and add them to matrix.py" and this should be fine, all > SSL versions will then be updated every 6 months and can also be > updated on demand for important releases. Well, I don't want to see the CI fail just for testing this, having the weekly one gives you the status before integration and is also a reminder. > It's similar to how I simply rerun the Coccinelle > patches from time to time to fix whatever crept in since the last release. > I disagree, porting to a new API is not something you would do just before a release, you need to do it progressively if possible, because it could introduce heavy development and sometimes discussions with the library developers and unfortunately that could take time. That would be too bad to postpone support for a new version because nobody looked at this during the development cycle, and the changes are too heavy to be integrated. -- William Lallemand
Re: Reproducible CI build with OpenSSL and "latest" keyword
On Tue, Dec 06, 2022 at 07:54:33PM +0500, Илья Шипицин wrote: > I recall I even promised to do something, but I did not :-) > > automatically determine "which is latest 3.0.x" does not make much sense, > it is stable branch, very conservative. we can stick to 3.0.7, for example. > I do not expect any breaking change between 3.0.7 and 3.0.8 I recall a discussion like this indeed, couldn't find the previous thread. There was cases of broken minor release for LibreSSL for example, so it's better to stick to a release for the push CI and upgrade once the weekly CI passed. > we can move "latest" to weekly, np. as for stable branches CI, I think them > do not have to follow the same rules as development branch, we can have > different matrix for stable and development. I think we could it this way: - weekly "latest" for libreSSL, OpenSSL, whateverSSL for HAProxy master branch - git push CI with fixed version in HAProxy master > I think I got the idea. > looks like you use the same github actions for stable branches. > Indeed, at some point the master branch become a stable branch, so we inherit all of this. > either I will manage to make them different or I will stick to > 3.0.something. hopefully tomorrow IMHO it should never be "latest" anywhere else than the weekly, we don't want to be disturbed by this when pushing our code. I don't think we need a weekly for the stable branch, so it could be conditionned by a check on the version, for example only started if there is '-dev' in the version. So we should probably: - Revert "latest" to "3.0.7" in the master, and backport the patch in the previous supported branches. (as far as 2.4 I think) - Introduce "3.1.0-alpha1" to master - Introduce "latest" to weekly master -- William Lallemand
Reproducible CI build with OpenSSL and "latest" keyword
Hello, We are experiencing difficulties with the way the CI matrix is generated with the SSL libraries. As I already mentionned, I don't really like the "latest" keyword for the OpenSSL version as it prevent us to have reproducible builds. It updates versions without warning, even major ones. Since OpenSSL 3.1.0-aplha1 was released we are affected by the problem, we stopped building with 3.0.x without noticing, and our internal CI for the stable branches start failing because of that. Majour versions must never change in the previous branches. What I suggest is to stop using "latest" for the "git push" CI, but using it only in a separate CI (once a day/week I don't know). And only use fixed version of the libraries on the CI so builds are not broken by external components. Because in my opinion the "git push" CI is to test our code, not the libraries. What do you guys think? -- William Lallemand
Re: Certificate picking order
Hi, On Sat, Nov 19, 2022 at 05:45:43PM +0100, William Edwards wrote: > Hello, > > When multiple SSL certificates exist for a given domain, which one does > HAProxy pick? > > I'm specifically interested in knowing what happens when: > > - Multiple certificates with the exact same set of common names exist The SNI and CN are registered in a tree and the match will depend on the declaration order. But using this order is not convenient in some cases, instead you could use the crt-list keyword that let you redefine which certificate should serve which SNI/CN. > - A more specific certificate exists, e.g. one wildcard certificate > (*.example.com) and one covering only a subdomain (foo.example.com) It first look for an exact match, then look for a wildcard. In case of a crt-list it also look for a negative entry. For example your could have in your crt-list: cert1.pem *.example.com !foo2.example.com !foo3.example.com cert2.pem foo2.example.com cert3.pem foo3.example.com > ... and if the order of .pem files matters in a `crt` directory. > They are registered in alphabetical order so it does. > I am unable to find this in the documentation. But I'm pretty sure I've > seen it in there before... > Regards, -- William Lallemand
Re: [PATCH] fix spelling "choosen" --> "chosen"
On Tue, Nov 01, 2022 at 12:16:16PM +0100, Willy Tarreau wrote: > Hi Ilya, > > On Tue, Nov 01, 2022 at 03:49:18PM +0500, ??? wrote: > > Hello, > > > > I'm not sure how good is idea to fix variable names. > > if we want to keep as is, I'd setup spelling exclusion. > > Interesting. I'm CCing the relevant maintainers, they're the best placed > to know if they're willing to fix the code now (hint: better sooner than > later :-)). > > Note before applying the patch, one "choosen" in a comment mistakenly > ended up as "chooen" instead of "chosen", so let's fix it before applying. > > Thanks! > Willy > > > - if (!tp->choosen) > > + if (!tp->chosen) > > return; > > > > - chunk_appendf(b, "\n\tversion_information:(choosen=0x%08x", > > tp->choosen); > > + chunk_appendf(b, "\n\tversion_information:(chosen=0x%08x", tp->coosen); I don't think it will even compile this way. > -- William Lallemand
Re: [PR] prelim-wolfSSL updates
Thanks for the pull request, we are going to take a look and test it. On Sun, Oct 23, 2022 at 12:23:02AM +0200, PR Bot wrote: > Dear list! > > Author: Uriah Pollock > Number of patches: 1 > > This is an automated relay of the Github pull request: >prelim-wolfSSL updates > > Patch title(s): >prelim-wolfSSL updates > > Link: >https://github.com/haproxy/haproxy/pull/1908 > > Edit locally: >wget https://github.com/haproxy/haproxy/pull/1908.patch && vi 1908.patch > > Apply locally: >curl https://github.com/haproxy/haproxy/pull/1908.patch | git am - > > Description: > > > Instructions: >This github pull request will be closed automatically; patch should be >reviewed on the haproxy mailing list (haproxy@formilux.org). Everyone is >invited to comment, even the patch's author. Please keep the author and >list CCed in replies. Please note that in absence of any response this >pull request will be lost. > -- William Lallemand
Re: coredump and traceback on the CI
On Thu, Oct 20, 2022 at 10:51:23PM +0500, Илья Шипицин wrote: > I would suggest to display vtest result failure only if vtest failed, > haproxy/vtest.yml at master · haproxy/haproxy (github.com) > <https://github.com/haproxy/haproxy/blob/master/.github/workflows/vtest.yml#L139> > > I doubt if there could be coredump together with successful vtest > Indeed that make sense, I'll do that. > just curious, was it only reproduced on CI ? not reproduced locally on > alpine ? > I tested on a local container but it didn't reproduce all the parameters to make it fail, my alpine version wasn't the right one in my container, even if I used :latest it wasn't the same, and the number of threads wasn't right either. Once I had the coredump I identified what was missing but I spend some time trying to change multiple parameters. -- William Lallemand
coredump and traceback on the CI
Hello List,
I had some difficulties today to reproduce a bug which was only
visible on the alpine container CI. So I found some way to investigate
directly from the CI.
The attached patch enables the coredumps and does a "gdb -ex 'thread
apply all bt full'" for the alpine/musl job.
I think this will help to debug a lot, I know there is also the ability
to get an artefact with the coredump, which could also be interesting,
but having the traceback on the CI page is easy.
If no one complain, I'll push the patch.
Cheers,
--
William Lallemand
>From 4465fe8c77aa2ce664ebfc46b41d20c4440d10cc Mon Sep 17 00:00:00 2001
From: William Lallemand
Date: Thu, 20 Oct 2022 15:01:01 +0200
Subject: [PATCH] CI: github: dump the backtrace of coredumps in the alpine
container
This patch allows to show the backtrace of a coredump produced in the
alpine/musl jobs.
It activates some option required by the containers to allow the
production of coredump, set a shared directory so the kernel could dump
the coredump within the container. Some debug packages were also added.
---
.github/workflows/musl.yml | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/.github/workflows/musl.yml b/.github/workflows/musl.yml
index 5a6b46a7b..ff1a0f780 100644
--- a/.github/workflows/musl.yml
+++ b/.github/workflows/musl.yml
@@ -12,14 +12,21 @@ jobs:
runs-on: ubuntu-latest
container:
image: alpine:latest
+options: --privileged --ulimit core=-1 --security-opt seccomp=unconfined
+volumes:
+ - /tmp/core:/tmp/core
steps:
+ - name: coredump setup
+run: |
+ ulimit -c unlimited
+ echo '/tmp/core/core.%h.%e.%t' > /proc/sys/kernel/core_pattern
- uses: actions/checkout@v3
- name: Install dependencies
-run: apk add gcc make tar git python3 libc-dev linux-headers pcre-dev pcre2-dev openssl-dev lua5.3-dev grep socat curl
+run: apk add gcc gdb make tar git python3 libc-dev linux-headers pcre-dev pcre2-dev openssl-dev lua5.3-dev grep socat curl musl-dbg lua5.3-dbg
- name: Install VTest
run: scripts/build-vtest.sh
- name: Build
-run: make -j$(nproc) CC=cc V=1 TARGET=linux-musl USE_LUA=1 LUA_INC=/usr/include/lua5.3 LUA_LIB=/usr/lib/lua5.3 USE_OPENSSL=1 USE_PCRE2=1 USE_PCRE2_JIT=1 USE_PROMEX=1
+run: make -j$(nproc) TARGET=linux-musl DEBUG_CFLAGS='-ggdb3' CC=cc V=1 USE_LUA=1 LUA_INC=/usr/include/lua5.3 LUA_LIB=/usr/lib/lua5.3 USE_OPENSSL=1 USE_PCRE2=1 USE_PCRE2_JIT=1 USE_PROMEX=1
- name: Show version
run: ./haproxy -vv
- name: Show linked libraries
@@ -30,6 +37,15 @@ jobs:
- name: Run VTest
id: vtest
run: make reg-tests VTEST_PROGRAM=../vtest/vtest REGTESTS_TYPES=default,bug,devel
+ - name: Show coredumps
+if: ${{ failure() }}
+run: |
+ ls /tmp/core/
+ for file in /tmp/core/core.*; do
+printf "::group::"
+gdb -ex 'thread apply all bt full' ./haproxy $file
+echo "::endgroup::"
+ done
- name: Show results
if: ${{ failure() }}
run: |
@@ -40,3 +56,4 @@ jobs:
echo "::endgroup::"
done
shopt -s nullglob
+
--
2.34.1
Re: [PATCH] CI: use proper version generating when {OPENSSL,LIBRESSL}_VERSION=latest semantic is used
On Tue, Oct 18, 2022 at 03:10:07PM +0500, Илья Шипицин wrote: > > Sorry I didn't see the first commit that introduced this behavior. I'm > > not sure we would want to replace the version automatically in the CI > > for OpenSSL. > > > > it was supposed behaviour for OPENSSL_VERSION=latest > Yes, that's exactly why I said that I missed the introduction of that change :-) > > Currently we are testing the stock OpenSSL of the ubuntu which is 1.1.1, > > the 1.0.2u and the "latest". The latest is currently a 3.0.x but once > > the 3.1.x is released we would still need the 3.0 branch. > > > > I think we should review our approach to "stock" and "latest" when > ubuntu-latest > will be 22.04 (it is shipped with 3.0.X) > > I'll have a look at your point as well Sure, that's not urgent, we will need to add a 1.1.1 separately in this case. > > I think we need something to test the latest release of a branch, and > > not the latest version of all branches. Maybe we could specify "3.0.x" > > to get the latest 3.0? > > > > maybe-maybe-maybe. > > we can introduce "latest in 3.0.x" I guess. not much to code. I think that's the most logical behavior we need for testing HAProxy without breaking the CI because of a major change in the library. What we need is to test our code for each of our commit, if the CI break on our commit because we changed the lib version it's difficult to know where the issue is. Maybe we could have a separated CI job with the "latest" version, so we ensure that this is running correctly before integrating the version to the "per-commit" CI jobs. What do you think about that? It seems like a good compromise to me. -- William Lallemand
Re: [PATCH] CI: use proper version generating when {OPENSSL,LIBRESSL}_VERSION=latest semantic is used
On Thu, Oct 13, 2022 at 08:54:38AM +0200, Willy Tarreau wrote: > Hi Ilya, > > On Tue, Oct 11, 2022 at 12:18:40PM +0500, ??? wrote: > > split patches attached. > > Sorry for the delay. Both applied now, thank you! > Willy > Hello, Sorry I didn't see the first commit that introduced this behavior. I'm not sure we would want to replace the version automatically in the CI for OpenSSL. Currently we are testing the stock OpenSSL of the ubuntu which is 1.1.1, the 1.0.2u and the "latest". The latest is currently a 3.0.x but once the 3.1.x is released we would still need the 3.0 branch. I think we need something to test the latest release of a branch, and not the latest version of all branches. Maybe we could specify "3.0.x" to get the latest 3.0? Regards, -- William Lallemand
Re: LibreSSL 3.6.0 QUIC support with HAProxy 2.7
On Thu, Oct 06, 2022 at 08:46:08AM +0500, Илья Шипицин wrote: > libressl-3.6.0 was released yesterday > > [image: image.png] > > > hopefully, github pipeline will pick it on the next build (it tries to pick > latest available). I'm confused, the CI is switching major branches automatically? > we can modify github pipeline to use quic for libressl builds > I think that's a good idea, indeed. -- William Lallemand
Re: LibreSSL 3.6.0 QUIC support with HAProxy 2.7
On Thu, Sep 15, 2022 at 01:06:25AM +0200, Aleksandar Lazic wrote: > Hi William. > > [...] > How about to change this to something like > > Built with SSL Library version > Running on SSL Library version > SSL library supports ... > > Because it's confusing :-) > > Built with OpenSSL version : LibreSSL 3.6.0 > > I thought also something like > > Built with (OpenSSL|LibreSSL) version : LibreSSL 3.6.0 > > But this looks ugly to me. > > I get your point, but this is still a library from the OpenSSL family, a fork which uses most of the OpenSSL API, you still have to build with USE_OPENSSL=1. It's the same for OpenSSL, LibreSSL, quicTLS, BoringSSL. At some point if we add a whole new API, for example gnuTLS or wolfssl, this would be a whole new API, and we would have to rename the defines and probably this line in haproxy -vv. -- William Lallemand
LibreSSL 3.6.0 QUIC support with HAProxy 2.7
Hello List,
We've just finished the portage of HAProxy for the next libreSSL
version which implements the quicTLS API.
For those interested this is how you are supposed to compile everything:
The libreSSL library:
$ git clone https://github.com/libressl-portable/portable libressl
$ cd libressl
$ ./autogen.sh
// The QUIC API is not public and not available in the shared
// library for now, you have to link with the .a
$ ./configure --prefix=/opt/libressl-quic/ --disable-shared
CFLAGS=-DLIBRESSL_HAS_QUIC
$ make V=1
$ sudo make install
HAProxy:
$ git clone http://git.haproxy.org/git/haproxy.git/
$ cd haproxy
$ make TARGET=linux-glibc USE_OPENSSL=1 USE_QUIC=1
SSL_INC=/opt/libressl-quic/include/ \
SSL_LIB=/opt/libressl-quic/lib/ DEFINE='-DLIBRESSL_HAS_QUIC'
$ ./haproxy -vv
HAProxy version 2.7-dev5-7eeef9-91 2022/09/14 - https://haproxy.org/
Status: development branch - not safe for use in production.
Known bugs: https://github.com/haproxy/haproxy/issues?q=is:issue+is:open
Running on: Linux 5.15.0-47-generic #51-Ubuntu SMP Thu Aug 11 07:51:15
UTC 2022 x86_64
Build options :
TARGET = linux-glibc
CPU = generic
CC = cc
CFLAGS = -O2 -ggdb3 -Wall -Wextra -Wundef
-Wdeclaration-after-statement -Wfatal-errors -Wtype-limits
-Wshift-negative-value -Wshift-overflow=2 -Wduplicated-cond -Wnull-dereference
-fwrapv -Wno-address-of-packed-member -Wno-unused-label -Wno-sign-compare
-Wno-unused-parameter -Wno-clobbered -Wno-missing-field-initializers
-Wno-cast-function-type -Wno-string-plus-int -Wno-atomic-alignment
-DLIBRESSL_HAS_QUIC
OPTIONS = USE_PCRE=1 USE_OPENSSL=1 USE_LUA=1 USE_ZLIB=1 USE_SYSTEMD=1
USE_QUIC=1
DEBUG = -DDEBUG_MEMORY_POOLS -DDEBUG_STRICT
Feature list : +EPOLL -KQUEUE +NETFILTER +PCRE -PCRE_JIT -PCRE2
-PCRE2_JIT +POLL +THREAD -PTHREAD_EMULATION +BACKTRACE -STATIC_PCRE
-STATIC_PCRE2 +TPROXY +LINUX_TPROXY +LINUX_SPLICE +LIBCRYPT +CRYPT_H -ENGINE
+GETADDRINFO +OPENSSL +LUA +ACCEPT4 -CLOSEFROM +ZLIB -SLZ +CPU_AFFINITY +TFO
+NS +DL +RT -DEVICEATLAS -51DEGREES -WURFL +SYSTEMD -OBSOLETE_LINKER +PRCTL
-PROCCTL +THREAD_DUMP -EVPORTS -OT +QUIC -PROMEX -MEMORY_PROFILING
Default settings :
bufsize = 16384, maxrewrite = 1024, maxpollevents = 200
Built with multi-threading support (MAX_TGROUPS=16, MAX_THREADS=256,
default=8).
Built with OpenSSL version : LibreSSL 3.6.0
Running on OpenSSL version : LibreSSL 3.6.0
OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes
OpenSSL library supports : TLSv1.0 TLSv1.1 TLSv1.2 TLSv1.3
Built with Lua version : Lua 5.4.3
Built with network namespace support.
Support for malloc_trim() is enabled.
Built with zlib version : 1.2.11
Running on zlib version : 1.2.11
Compression algorithms supported : identity("identity"),
deflate("deflate"), raw-deflate("deflate"), gzip("gzip")
Built with transparent proxy support using: IP_TRANSPARENT
IPV6_TRANSPARENT IP_FREEBIND
Built with PCRE version : 8.39 2016-06-14
Running on PCRE version : 8.39 2016-06-14
PCRE library supports JIT : no (USE_PCRE_JIT not set)
Encrypted password support via crypt(3): yes
Built with gcc compiler version 11.2.0
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 multiplexer protocols :
(protocols marked as cannot be specified using 'proto'
keyword)
quic : mode=HTTP side=FE mux=QUIC flags=HTX|NO_UPG|FRAMED
h2 : mode=HTTP side=FE|BE mux=H2flags=HTX|HOL_RISK|NO_UPG
fcgi : mode=HTTP side=BE mux=FCGI flags=HTX|HOL_RISK|NO_UPG
: mode=HTTP side=FE|BE mux=H1flags=HTX
h1 : mode=HTTP side=FE|BE mux=H1flags=HTX|NO_UPG
: mode=TCP side=FE|BE mux=PASS flags=
none : mode=TCP side=FE|BE mux=PASS flags=NO_UPG
Available services : none
Available filters :
[BWLIM] bwlim-in
[BWLIM] bwlim-out
[CACHE] cache
[COMP] compression
[FCGI] fcgi-app
[SPOE] spoe
[TRACE] trace
Regards,
--
William Lallemand
