alt Hacker NewsWolfSSL sucks too, so now what?
Comments
The blog author seems like a real piece of work. He ghosts the WolfSSL maintainer for over 160 days and when asked to open a new, more specific issue, he instead chooses to write a blog post denigrating the project. The WolfSSL maintainer was nothing but courteous and helpful throughout the entire exchange.
>...they aren't really interested in RFC compliance.
Yeah, well "feld" can't claim to be "interested in RFC compliance" either when he ghosts the issue for months and chooses to write blog posts instead of opening a new issue. Good grief.
If this is what the FreeBSD community is like, I want nothing to do with them.
> Asking me to open a new issue to discuss this behavior instead of it being a high priority for them to open up a new issue internally to fix this is odd. I'm not here to do their homework for them.
Why are people so entitled? How much is the author paying WolfSSL to make demands of them?
> Currently I've only identified one victim of this decision, but there's bound to be more out there.
Oh yes, he has become a victim of using a FOSS library.
What really gets me is the commenter at the end of the GH issue lecturing a maintainer on policy in their own tracker.
If you change your software to comply with "middleboxes" that don't follow standards, then you're admitting your own software is faulty, not theirs. In this case, though, the TLS v1.3 standard actually carved out a portion of the standard itself just to comply with shitty middleware. You know what that says to me? Standards are pointless. Just make a middlebox, make it do whatever the hell you want, and everyone else will bend over to support you.
This is yet one more reason why we need software building codes and regulations. If software people are unwilling to protect their own standards, the government should. It might fix the 20-year mistake of allowing "the web" to become a defacto network transport layer and application platform.
Regarding HAProxy, they ended up using AWS-LC in their new Debian/Ubuntu “performance” packages: https://www.haproxy.com/blog/fresh-from-aws-reinvent-superch...
BearSSL by Thomas Pornin is always worth checking in on, not sure what the current status is but looks like it received a commit last year.
We need something with TLS in the name for the next one so people stop getting confused.
Usability-wise (I do not need many features or compliance for FIPS) I have been happy with Botan: https://botan.randombit.net/
Many people and projects have tried to ditch OpenSSL in favor of LibreSSL, WolfSSL, MbedTLS, etc, but by now many have returned to OpenSSL. The IQ curve meme with "just use OpenSSL" applies.
There is also s2n-tls. I'm working on a GSS-based interface to TLS, much like SChannel is an SSPI-based interface to TLS.
Go can create C ABI shared libraries, I think OpenSSL-compatible C bindings to Go's crypto/tls would be a really interesting option.
Nothing wrong with LibreSSL, really.
If it's good enough for openbsd, it's good enough for you as well.
Particularly, they put in a lot of work on making it a drop-in replacement for openssl, and in making the portable version work well in many platforms.
Only for distributions to fail to take the sorely needed step of actually making the switch.
> Last updated on 2026-12-13
Yeah, no, I can't find a way to read this in which it's not in the future.
In the age of GPT Codex 5.3 and Claude Opus 4.6. Just write your own.
NanoSSL by DigiCert https://dev.digicert.com/trustcore-sdk/nanossl.html
It's opensource -> https://github.com/digicert/trustcore
This is the WolfSSL maintainer's response[1]
> This ticket is rather long and has a lot of irrelevant content regarding this new topic. If I need to bring in a colleague I do not want them to have to wade through all the irrelevant context. If you would like, please open a new issue with regards to how we support middlebox compatibility.
The author turns this into:
> The GitHub issue comment left at the end leads me to believe that they aren't really interested in RFC compliance. There isn't a middleground here or a "different way" of implementing middlebox compatibility. It's either RFC compliant or not. And they're not.
This is a bad-faith interpretation of the maintainer's response. They only asked to open a new, more specific issue report. The maintainer always answered within minutes, which I find quite impressive (even after the author ghosted for months). The author consumed the maintainer's time and shouldn't get the blame for the author's problems.
[1]: https://github.com/wolfSSL/wolfssl/issues/9156