I finally tried to replace #openssl with #aws-lc on some of my services. Unfortunately, #nginx and #mosquitto lack support for it. Instead, I successfully switched #BIND to use aws-lc.

I later also noticed that the rustls compatibility shim is in nixpkgs 25.05, but here BIND is missing some variables. And despite the wrapper being explicitly made for nginx, it also fails here with

/nix/store/mkvc0lnnpmi604rqsjdlv1pmhr638nbd-binutils-2.44/bin/ld: objs/src/stream/ngx_stream_ssl_module.o: in function `ngx_stream_ssl_servername':
/build/nginx-1.28.0/src/stream/ngx_stream_ssl_module.c:606:(.text+0xd59): undefined reference to `SSL_SESSION_get0_hostname'

A shame. I wanted to change to more modern libraries.

Untested: dovecot and postfix (they lack a services.(dovecot2/postfix).package variable to easily change the used package. A PR for dovecot is already open to add support for it.

Would you say this is an accurate description of (some of the) #OpenSSL forks family tree?

(These are the OpenSSL forks #curl supports.)

I need help. First the question: On #FreeBSD, with all ports built with #LibreSSL, can I somehow use the #clang #thread #sanitizer on a binary actually using LibreSSL and get sane output?

What I now observe debugging #swad:

- A version built with #OpenSSL (from base) doesn't crash. At least I tried very hard, really stressing it with #jmeter, to no avail. Built with LibreSSL, it does crash.
- Less relevant: the OpenSSL version also performs slightly better, but needs almost twice the RAM
- The thread sanitizer finds nothing to complain when built with OpenSSL
- It complains a lot with LibreSSL, but the reports look "fishy", e.g. it seems to intercept some OpenSSL API functions (like SHA384_Final)
- It even complains when running with a single-thread event loop.
- I use a single SSL_CTX per listening socket, creating SSL objects from it per connection ... also with multithreading; according to a few sources, this should be supported and safe.
- I can't imagine doing that on a *single* thread could break with LibreSSL, I mean, this would make SSL_CTX pretty much pointless
- I *could* imagine sharing the SSL_CTX with multiple threads to create their SSL objects from *might* not be safe with LibreSSL, but no idea how to verify as long as the thread sanitizer gives me "delusional" output

"download time is reduced by ~13%" (for #curl)

... by adding some odd #OpenSSL functions we didn't know existed.

https://github.com/curl/curl/pull/17548

More interesting progress trying to make #swad suitable for very busy sites!

I realized that #TLS (both with #OpenSSL and #LibreSSL) is a *major* bottleneck. With TLS enabled, I couldn't cross 3000 requests per second, with somewhat acceptable response times (most below 500ms). Disabling TLS, I could really see the impact of a #lockfree queue as opposed to one protected by a #mutex. With the mutex, up to around 8000 req/s could be reached on the same hardware. And with a lockfree design, that quickly went beyond 10k req/s, but crashed.

So I read some scientific papers ... and redesigned a lot (*). And now it finally seems to work. My latest test reached a throughput of almost 25k req/s, with response times below 10ms for most requests! I really didn't expect to see *this* happen. Maybe it could do even more, didn't try yet.

Open issue: Can I do something about TLS? There *must* be some way to make it perform at least a *bit* better...

(*) edit: Here's the design I finally used, with a much simplified "dequeue" because the queues in question are guaranteed to have only a single consumer: https://dl.acm.org/doi/10.1145/248052.248106

I wrote about #openssl #jdk21 and #pkcs12 #cryptography #debian #fedora https://kushaldas.in/posts/openssl-legacy-and-jdk-21.html
#java

May’s #Tumbleweed update rolled out #QEMU 10.0 for improved virtualization and #OpenSSL 3.5.0 with post-#quantum #crypto Security got serious with #CVE fixes #openSUSE https://news.opensuse.org/2025/06/02/tw-monthly-update-may/

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

@forthy42 doof nur dass es keine Alternativen abselts von #OpenSSL, #LibreSSL & #NSS gibt - und wer #PCIDSS erfüllen muss, ist auf zertifizierte Binaries angewiesen!

“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

Does anyone know how this new SSL cert expiry date thing is going to affect things like user authentication with SSL certs, i.e. for openvpn.

If we're running our own CA, can I get safari, chrome et al to accept longer cert expiry?

Meanwhile in #curl land, we can now do #HTTP3 with #ngtcp2 1.12.0 and #OpenSSL 3.5.

Thanks to lots of amazing people, including @icing and Tatsuhiro of ngtcp2 of course.

#Linux Weekly Roundup for April 13th, 2025: #LMDE 7 getting OEM support, #Pinta 3.0 ported to GTK4, #DXVK 2.6.1 improves support for #AMD Vega GPUs and several games, #OpenSSL 3.5, #fwupd 2.0.8, #IPFire gets post-quantum cryptography support, and more https://9to5linux.com/9to5linux-weekly-roundup-april-13th-2025

Can distros ship #git that ends up using #OpenSSL (via libcurl)? This bug was filed against Debian:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1094969

Some browsers and also #OPenSSL 3.5.0 support already #PQ #KEMs for key exchange to to provide secure key establishment resistance.

The (real soon now) to be released testssl.sh 3.2 final will include handshake simulation, see last column:

It looks like the #OpenSSL QUIC API might be supported in the coming #ngtcp2 1.12.0 release:

https://github.com/ngtcp2/ngtcp2/pull/1582

This could be exciting for #curl users building with #OpenSSL ...

#OpenSSL 3.5.0 LTS release with some #PQC algorithms, server side #QUIC support and more