[no subject]
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: Error While deviceatlas compile/make from source
Sorry for the inconvenience, there was indeed an essential missing component to be fully workable. It had been now fixed, from the same URL as before. Kindest regards. On Wed, 4 Oct 2023 at 00:08, Mahendra Patil wrote: > > Downloaded all latest and tried but still error > > [root@govinda opt]# /opt/haproxy-ssl/sbin/haproxy -f > /opt/haproxy-ssl/conf/haproxy.cfg > [NOTICE] (28500) : haproxy version is 2.8.3-86e043a > [NOTICE] (28500) : path to executable is /opt/haproxy-ssl/sbin/haproxy > > *[ALERT](28500) : config : deviceatlas : data could not be compiled.* > > > > > > On Fri, Sep 29, 2023 at 4:44 PM David CARLIER wrote: > >> Hi Mahendra, sorry for late reply but you cam download a JSON from this >> page https://deviceatlas.com/deviceatlas-haproxy-module >> now they are compatible with the V3 api. >> >> Kind regards. >> >> On Wed, 20 Sept 2023 at 23:50, Mahendra Patil >> wrote: >> >>> *After installation haproxy not able to start , show below error* >>> >>> [root@govinda opt]# /opt/haproxy-ssl/sbin/haproxy -f >>> /opt/haproxy-ssl/conf/haproxy.cfg >>> [NOTICE] (42915) : haproxy version is 2.8.3-86e043a >>> [NOTICE] (42915) : path to executable is /opt/haproxy-ssl/sbin/haproxy >>> [ALERT](42915) : config : deviceatlas : >>> '/opt/deviceatlas/20230802_compact.json' json file is invalid. >>> >>> On Tue, Sep 19, 2023 at 5:36 PM David CARLIER >>> wrote: >>> We are almost there, now remains the linkage part to pass. In your /opt/deviceatlas-enterprise-c-3.2 folder, there should be a `include` and a `lib` or a `lib64` folder So for the last command, what needs to be done instead is one of the following (no need to repeat step 1) : make TARGET=linux-glibc USE_PCRE=1 USE_OPENSSL=1 USE_ZLIB=1 USE_DEVICEATLAS=1 DEVICEATLAS_INC=/opt/deviceatlas-enterprise-c-3.2/include DEVICEATLAS_LIB=/opt/deviceatlas-enterprise-c-3.2/lib DEVICEATLAS_LDFLAGS="-L/opt/deviceatlas-enterprise-c-3.2/lib -Wl,-rpath,/opt/deviceatlas-enterprise-c-3.2/lib -lda" or make TARGET=linux-glibc USE_PCRE=1 USE_OPENSSL=1 USE_ZLIB=1 USE_DEVICEATLAS=1 DEVICEATLAS_INC=/opt/deviceatlas-enterprise-c-3.2/include DEVICEATLAS_LIB=/opt/deviceatlas-enterprise-c-3.2/lib64 DEVICEATLAS_LDFLAGS="-L/opt/deviceatlas-enterprise-c-3.2/lib64 -Wl,-rpath,/opt/deviceatlas-enterprise-c-3.2/lib64 -lda" The only difference is `lib` vs `lib64` Hope it's useful. Kindest regards. On Tue, 19 Sept 2023 at 12:52, Mahendra Patil < mahendra.pa...@naaptol.com> wrote: > > 1) > cd /opt/deviceatlas-enterprise-c-3.2 > cmake . -DCMAKE_INSTALL_PREFIX=/opt/deviceatlas-enterprise-c-3.2 > -DCMAKE_C_FLAGS="-std=gnu99" > make > make install > > 2) > cd haproxy-2.8.3 > make TARGET=linux-glibc USE_PCRE=1 USE_OPENSSL=1 USE_ZLIB=1 > USE_DEVICEATLAS=1 > DEVICEATLAS_INC=/opt/deviceatlas-enterprise-c-3.2/include > DEVICEATLAS_LIB=/opt/deviceatlas-enterprise-c-3.2/lib > > LD haproxy > /usr/bin/ld: cannot find -lda > collect2: error: ld returned 1 exit status > make: *** [haproxy] Error 1 > > > > > > On Tue, Sep 19, 2023 at 10:19 AM David CARLIER > wrote: > >> Hi, >> >> Since you build the DeviceAtlas library from cmake prior, the >> following steps are more appropriate : >> 1/ Inside the deviceatlas-enterprise-c-3.2 folder >> cmake . -DCMAKE_INSTALL_PREFIX=/opt/deviceatlas-enterprise-c-3.2 >> -DCMAKE_C_FLAGS="-std=gnu99" >> make >> make install >> >> 2/ Inside the haproxy-2.8.3 folder >> >> make TARGET=linux-glibc USE_PCRE=1 USE_OPENSSL=1 USE_ZLIB=1 >> USE_DEVICEATLAS=1 >> DEVICEATLAS_INC=/opt/deviceatlas-enterprise-c-3.2/include >> DEVICEATLAS_LIB=/opt/deviceatlas-enterprise-c-3.2/lib >> >> Let me know if you have any further question. >> >> On Tue, 19 Sept 2023 at 00:02, Mahendra Patil < >> mahendra.pa...@naaptol.com> wrote: >> >>> Thanks for yours prompt reply about deviceatlas-enterprise-c-3.2 >>> error while make >>> after yours suggestion deviceatlas-enterprise-c-3.2 *make *works >>> fine >>> >>> But while using with haproxy-2.8.3 version gives following error >>> >>> [root@govinda opt]# cd haproxy-2.8.3 >>> [root@govinda haproxy-2.8.3]# make TARGET=linux-glibc USE_PCRE=1 >>> USE_OPENSSL=1 USE_ZLIB=1 USE_DEVICEATLAS=1 >>> DEVICEATLAS_SRC=/opt/deviceatlas-enterprise-c-3.2/Src/ >>> CC src/ev_poll.o >>> CC src/ev_epoll.o >>> CC src/cpuset.o >>> CC src/ssl_sock.o >>> CC src/ssl_ckch.o >>> CC src/ssl_sample.o >>> CC src/ssl_crtlist.o >>> CC src/cfgparse-ssl.o >>> CC src/ssl_utils.o >>> CC src/jwt.o >>> CC src/ssl_ocsp.o >>> CC
Re: OCSP update restarts all proxies
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
Re: [PATCH 0/4] Support server-side sending and forwarding of arbitrary PPv2 TLVs
Hi Alexander, On Wed, Oct 04, 2023 at 12:56:07PM +, Stephan, Alexander wrote: > Can you find them if you search for the text that is shown in the archive? Not at all, not even in the spam logs :-( Please note that we've had a short outage from an haproxy core filling the whole FS ~10 days ago, I don't know if that could have matched, but in any case at least you should have received a delivery error. > If not, I can of course send them again. Yes please do and CC me so that I know when they're sent and can compare if I continue not to see them on the ML. Thank you! Willy
RE: [PATCH 0/4] Support server-side sending and forwarding of arbitrary PPv2 TLVs
Hi Willy, Maybe it is because I replied to cover letter and not to the individual patches? This time, I sent them as separate mails, with no attachment. The patches should be responses to the cover letter I replied to in the previous mail. Here are the links to the patches again: [PATCH 1/4] MEDIUM: server: Parse generic type-value pairs as proxy-v2-options: https://www.mail-archive.com/haproxy@formilux.org/msg44023.html [PATCH 2/4] MEDIUM: connection: Send out generically allocated proxy-v2-options: https://www.mail-archive.com/haproxy@formilux.org/msg44024.html [PATCH 3/4] LOW: connection: Add TLV update function: https://www.mail-archive.com/haproxy@formilux.org/msg44025.html [PATCH 4/4] MEDIUM: tcp-act: Add new set-tlv TCP action for PPv2 TLVs: https://www.mail-archive.com/haproxy@formilux.org/msg44026.html Can you find them if you search for the text that is shown in the archive? If not, I can of course send them again. Best, Alexander -Original Message- From: Willy Tarreau Sent: Tuesday, October 3, 2023 11:27 AM To: Stephan, Alexander Cc: haproxy@formilux.org Subject: Re: [PATCH 0/4] Support server-side sending and forwarding of arbitrary PPv2 TLVs Hi Alexander, On Mon, Oct 02, 2023 at 10:22:17AM +, Stephan, Alexander wrote: > Hi, > > I am back from my vacation and I wanted to ask whether somebody has had the > chance to look at this. > A short ACK that the changes will be reviewed would be much appreciated. I'm sorry but I can't find any trace of the original. Could you please resend it ? thank you! Willy
Re: OCSP update restarts all proxies
On 04/10/2023 03:05, Shawn Heisey wrote: On 10/3/23 01:33, Remi Tricot-Le Breton wrote: This command relies on the same task that performs the automatic update. What it does is basically add the certificate at the top of the task's update list and wakes it up. The update is asynchronous so we can't return a status to the CLI command. In order to check if the update was successful you can display the contents of the updated OCSP response via the "show ssl ocsp-response" command. If the response you updated is also set to be updated automatically, you can also use the "show ssl ocsp-updates" command that gives the update success and failure numbers as well as the last update status for all the responses registered in the auto update list. I have no idea how to get an interactive session going on the stats socket so that I can see whatever response a command generates. The only command I know for the socket is for the old-style OCSP update where the OCSP response is obtained with openssl, converted to base64, and sent to the socket. No response comes back when using socat in this way. You just have to run the following commands : $ echo "update ssl ocsp-response " | socat /path_to_socket/haproxy.sock - This command does not return anything (which is normal because the update will be performed asynchronously). You could see some log lines being emitted by your haproxy (depending on your log configuration) such as the following : <134>Oct 4 13:28:49 haproxy[14955]: -:- [04/Oct/2023:13:28:49.910] /path_to_cert/server_ocsp.pem.rsa 1 "Update successful" 0 1 You can then either check the contents of your OCSP response : $ echo "show ssl ocsp-response " | socat /path_to_socket/haproxy.sock - or, if your tested OCSP response had the 'ocsp-update' option set to 'on', you could dump the contents of the update tree thanks to the "echo ssl ocsp-updates" command: $ echo "show ssl ocsp-updates" | socat /tmp/haproxy.sock - OCSP Certid | Path | Next Update | Last Update | Successes | Failures | Last Update Status | Last Update Status (str) 303b300906052b0e03021a050004148a83e0060faff709ca7e9b95522a2e81635fda0a0414f652b0e435d5ea923851508f0adbe92d85de007a02021015 | /path_to_cert/server_ocsp.pem.rsa | 04/Oct/2023:14:28:49 +0200 | 04/Oct/2023:13:28:49 +0200 | 1 | 0 | 1 | Update successful The "Successes" and "Failures" counters should change when you call the "update ssl ocsp-response" CLI command. Here is my old script for OCSP updates, which I stopped using once I learned how to set up haproxy to do it automatically: https://paste.elyograg.org/view/5e88c914 Rémi LB
