On Wed, Jul 03, 2024 at 11:18:12PM +0200, Илья Шипицин wrote: > Subject: Re: [ANNOUNCE] haproxy-3.1-dev2 > сб, 29 июн. 2024 г. в 12:01, Willy Tarreau <w...@1wt.eu>: > > > Hi, > > > > HAProxy 3.1-dev2 was released on 2024/06/29. It added 45 new commits > > after version 3.1-dev1. > > > > Several fixes related to the recent 3.0 release are present in this > > version, as well as a few older ones. Most visible are three QUIC > > crashes, a possible double free on stick-tables, issues affecting > > aws-lc with ECDSA, a risk of server flapping when DNS resolution > > times out, and the usual amount of small fixes all over the place. > > > > In addition we've been notified by Yuki Mogi of FFRI Security that > > some of our pseudo-headers in H3 were not sanitized enough and that > > these could theoretically be abused with some severely non-compliant > > backend servers, so this was fixed as well. This will be backported > > to the next stable versions as it's not dramatic enough to warrant a > > release on its own. > > > > The "show dev" command was improved to report command-line args as > > well as boot & current capabilities. Linux capabilities switched to > > v3 instead of v1 in order to avoid a deprecation warning on recent > > kernels. We've checked the impacts and apparently there are none, > > beyond the lack of support of kernels prior to 2.6.26, so we'll soon > > backport it to 3.0 so as to silence the annoying warning users are > > facing. > > > > A date converter was added to take an HTTP date on input and produce > > a UNIX timestamp on output. This will help calculate expiration delays > > for example. > > > > The sigalg feature was added for aws-lc, which, I think, should now > > match 1:1 the features level of openssl (unless I'm missing something). > > > > it is VERY close to openssl. however there are few gaps. > the one I'm aware of is > > haproxy/include/haproxy/quic_tls.h at master · haproxy/haproxy (github.com) > <https://github.com/haproxy/haproxy/blob/master/include/haproxy/quic_tls.h#L143-L154> > > aws-lc implements chacha20_poly1305 in a different way than QuicTLS. > and if that gap is eliminated, it will be a good point to declare aws-lc as > a recommended QUIC lib. > > if we compare aws-lc against openssl-1.1 (not quictls), it is indeed > matches (maybe except some niche features like async) >
BoringSSL, LibreSSL, and AWS-LC uses the EVP_AEAD API, basically we would need to use EVP_aead_chacha20_poly1305() instead of EVP_chacha20_poly1305(), and EVP_aead_chacha20_poly1305() instead of EVP_chacha20() and uses the EVP_AEAD functions. IMHO this is not a huge change and this is doable, we just need to invest some time on it. Regards, -- William Lallemand
