In case you're interested in running a bleeding edge #reverseproxy with an optimized #SSL library: read this blog post (of mine) on "Compiling HAProxy with WolfSSL":

In case you're interested in running a bleeding edge #reverseproxy with an optimized #SSL library: read this blog post (of mine) on "Compiling HAProxy with WolfSSL":
Prepare to poo your pants.
OpenSSL provides a few helpers to compare certificates.
X509_cmp(), which returns 0 on a match, and
EVP_PKEY_cmp(), which returns 1 on a match.
It's OK, tan-coloured landmines are safe to step on. Olive-coloured landmines will explode and you will die.
Adding what was missing for intermediate certificates, I had great fun with #OpenSSL #API again. I mean, it never gets old. First test gave me a nice crash of #swad. Because ....
Well, to use a certificate (type X509 *), you call SSL_CTX_use_certificate(). Docs say "On success the reference counter of the x is incremented." (where x means the certificate). Great, so, call X509_free() directly afterwards to ensure this certificate gets destroyed whenever the SSL context gets destroyed.
So, just call the same function again for the intermediate certificates? No ... but there's SSL_CTX_add_extra_chain_cert() which *can* be used multiple times. Nice, call it in a loop as long as I find additional certificates in the cert file, and X509_free() them all directly after adding.
And then observe the crash. Well, it's documented, the manpage for SSL_CTX_add_extra_chain_cert() tells:
"The x509 certificate provided to SSL_CTX_add_extra_chain_cert() will be freed by the library when the SSL_CTX is destroyed. An application should not free the x509 object."
So, clearly my fault not reading this before. Consistency in API design is so overrated.
#OpenSSL -- Call for speakers at the inaugural OpenSSL Conference
https://openssl-foundation.org/post/2025-05-14-call-for-speakers/?utm_source=atom_feed
From #OpenSSL -- Blog on OpenSSL Foundation
EVP_CIPHER_CTX_copy for AES-GCM with libssl 3.0.2-0ubuntu1.19 not working #2204 #openssl
In case you haven't seen it yet, check out the analysis of the devastating state of [mostly] modern #OpenSSL by members of haproxy at https://www.haproxy.com/blog/state-of-ssl-stacks - hard to imagine such massive performance regressions getting into mainline linux distributions unnoticed by the distributors. #linux #ssl
#apt-listchanges: News
---------------------
#curl (8.13.0-2) unstable; urgency=medium
The curl #CLI is now back to using #OpenSSL, instead of #GnuTLS:
HTTP/3 support is still there, compared to the GnuTLS curl CLI.
The performance of HTTP/3 on OpenSSL is not as good, but it's also not used
by default.
-- Samuel Henrique <samueloph@debian.org> Sun, 06 Apr 2025 22:13:18 +0100
Dans ce (long et très détaillé) article sur l’état des stacks SSL, l’équipe de #haproxy (confirmée par d’autres équipes telles que Curl, Akamai, Microsoft…) tacle lourdement #OpenSSL sur la qualité du code et surtout sur la gouvernance du projet. Ça pique.
https://www.haproxy.com/blog/state-of-ssl-stacks
Long, but great read from #HAProxy on the state of #TLS libraries. Includes some scathing remarks about the #OpenSSL project.
“The development team has degraded their project’s quality, failed to address ongoing issues, and consistently dismissed widespread community requests for even minor improvements.”
“This unfortunate situation considerably hurts QUIC protocol adoption. It even makes it difficult to develop or build test tools to monitor a QUIC server.”
“When some of the project members considered a 32% performance regression ‘pretty near’ the original performance, it signaled to our development team that any meaningful improvement was unlikely.”
“In blunt terms: running OpenSSL 3.0.2 as shipped with Ubuntu 22.04 results in 1/100 of #WolfSSL’s performance on identical hardware! To put this into perspective, you would have to deploy 100 times the number of machines to handle the same traffic, solely because of the underlying SSL library.”
“AWS-LC looks like a very active project with a strong community. […] Even the recently reported performance issue was quickly fixed and released with the next version. […] This is definitely a library that anyone interested in the topic should monitor.”
#OpenSSL #BoringSSL #WolfSSL #AWSLC #HAProxy #OpenSource #FreeSoftware #FOSS #OSS #TLS #QUIC
https://www.haproxy.com/blog/state-of-ssl-stacks
Nmap 7.96 Launches with Lightning-Fast DNS and 612 Scripts https://thecyberexpress.com/nmap-7-96-released/ #TheCyberExpressNews #TheCyberExpress #FirewallDaily #DNSresolution #NmapProject #CyberNews #Nmap7.96 #OpenSSL #Nmap
#tls #openssl excellent thought provoking write up from Willy Tarreau and team at haproxy.com https://www.haproxy.com/blog/state-of-ssl-stacks#recommendations-for-haproxy-users TLDR openssl3.x is a performance train wreck at scale and if you are a large site you should consider alternatives.
Some other relevant info
- https://github.com/icing/blog/blob/main/curl-h3-performance.md
- https://github.com/haproxy/wiki/wiki/SSL-Libraries-Support-Status
#OpenSSL -- Have Your Say! Vote Now in the Technical Advisory Committee Elections and Support Your Community
https://openssl-corporation.org/post/2025-04-28-tac25-elections/?utm_source=atom_feed
From #OpenSSL -- Blog on OpenSSL Corporation