Thanks to @vsz this is quickly becoming the most thorough and detailed resource on the #OpenSSL fork situation. Which fork does what and how?

https://github.com/curl/curl/wiki/OpenSSL-forks

In October, I gave a talk about post-quantum #cryptography at the #OpenSSL Conference in Prague. Yesterday, the video dropped. If you're interested, head to https://www.youtube.com/watch?v=sXHEweoTj60!

In October, I gave a talk about post-quantum #cryptography at the #OpenSSL Conference in Prague. Yesterday, the video dropped. If you're interested, head to https://www.youtube.com/watch?v=sXHEweoTj60!

FYI #openssl v3.6.0 breaks SSL in #ruby and therefore #mastodon sidekick https://github.com/ruby/openssl/issues/949

FYI #openssl v3.6.0 breaks SSL in #ruby and therefore #mastodon sidekick https://github.com/ruby/openssl/issues/949

OpenSSL 3.5.3 introduces a regression that makes ssh break on openssl version check.
https://github.com/openssl/project/issues/1621

If you use Alpine Linux:
- 3.22: make sure you get >=3.5.3-r1
- edge: make sure you get >=3.5.3-r2

Those include backports of upstream fixes.

Sorry for the inconvenience.

#AlpineLinux #OpenSSL #regression

https://github.com/nginx/nginx/pull/840

If you want to see ECH in nginx sooner rather than later, please jump in and review, give feedback, thumbs up, etc.

#EncryptedClientHello#TLS#OpenSSL

https://github.com/nginx/nginx/pull/840

If you want to see ECH in nginx sooner rather than later, please jump in and review, give feedback, thumbs up, etc.

#EncryptedClientHello#TLS#OpenSSL

Just released: #swad 0.12 🥂

swad is the "Simple Web Authentication Daemon". It basically offers adding form + #cookie #authentication to your reverse proxy (designed for and tested with #nginx "auth_request"). I created it mainly to defend against #malicious_bots, so among other credential checker modules for "real" logins, it offers a proof-of-work mechanism for guest logins doing the same #crypto #challenge known from #Anubis.

swad is written in pure #C with minimal dependencies ( #zlib, #OpenSSL or compatible, and optionally #PAM), and designed to work on any #POSIX system. It compiles to a small binary (200 - 300 kiB depending on compiler and target platform).

This release brings (among a few bugfixes) improvements to make swad fit for "heavy load" scenarios: There's a new option to balance the load across multiple service worker threads, so all cores can be fully utilized if necessary, and it now keeps lots of transient objects in pools for reuse, which helps to avoid memory fragmentation and ultimately results in lower overall memory consumption.

Read more about it, download the .tar.xz, build and install it .... here:

https://github.com/Zirias/swad

Oh boy, I have a lead! And it's NOT related to #TLS. I finally noticed another pattern: #swad only #crashed when running as a #daemon. The daemonizing wasn't the problem, but the default logging configuration attached to it: "fake async", by letting a #threadpool job do the logging.

Forcing THAT even when running in foreground, I can finally reproduce a crash. And I wouldn't be surprised if that was actually the reason for crashing "pretty quickly" with #LibreSSL (and only rarely with #OpenSSL), I mean, something going rogue in your address space can have the weirdest effects.

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 😳

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

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. 🤪