WolfSSL sucks too, so now what?

https://blog.feld.me/posts/2026/02/wolfssl-sucks-too/

by thomasjb • 5 months ago

148 128 5 months ago

blog.feld.me

ospray• 5 months ago

We need something with TLS in the name for the next one so people stop getting confused.

magicalhippo• 5 months ago

MbedTLS[1] got your back!

[1] https://www.trustedfirmware.org/projects/mbed-tls/

anthk2• 5 months ago

That's being used by Dillo and it's working really well even on legacy computers.

weinzierl• 5 months ago

rustls is there. It has TLS in the name, it is good and there is a C FFI wrapper.

gspr6• 5 months ago

Rustls still outsources cryptographic primitives. I believe the currently supported providers of those are… drumroll… AWS-LC and Ring. The latter is a fork of BoringSSL. The article describes AWS-LC and BoringSSL as "Googled and Amazoned to death; they don't care about anyone but their own use cases".

The state of things sucks :-(

koakuma-chan2• 5 months ago

rustls doesn't have its own implementation of cryptography, you have to choose a provider like openssl or aws lc

dwedge• 5 months ago

A c wrapper to rust feels like we've gone full circle

zephen• 5 months ago

You're obviously looking for lastLs.

account42• 5 months ago

But then how will we spot the pedants.

MrBuddyCasino• 5 months ago

Now what? BearSSL.

kevin_thibedeau• 5 months ago

MbedTLS

aidenn0• 5 months ago

I don't know if it's still the case, but MbetTLS used to change its API as often as I change my socks.

mythz• 5 months ago

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.

[1] https://bearssl.org

jorams• 5 months ago

BearSSL is really cool, but it claims beta quality with the latest release in 2018, doesn't support TLS 1.3, and hasn't seen meaningful development in years. It's averaging about 1 commit per year recently, and they're not big ones.

embedding-shape• 5 months ago

Where is Bellard when we need him?

eptcyka2• 5 months ago

There’s always rustls.

LtWorf• 5 months ago

FIPS compliant?

eptcyka2• 5 months ago

It is if you use the FIPS compliance feature - then you also depend on aws-lc, but only for the crypto primitives.

gspr6• 5 months ago

The state of things sucks :-(

fulafel2• 5 months ago

From safety point of view that's actually good enough for "perfect is the enemy of good" to apply here.

Cryptographic primitives are much much safer in C (and assembly) than protocol handling, certificates etc.

They are basically just "fixed size data block in, fixed size data block out". You can't overflow a buffer, you can't use-after-free etc, you can't confuse inner protocol serialization semantics with outer protocol serialization semantics, you can't confuse a state machine, you can't have a concurrency bug[1] etc.

C memory safety vulnerabilities arise from trying to handle these dynamic things which rustls fixes.

(Also, there are third party crypto providers implemented in Rust)

[1] from memory safety pov; for side channels rust doesn't have advantages anyway

saqrais• 5 months ago

NanoSSL by DigiCert https://dev.digicert.com/trustcore-sdk/nanossl.html

It's opensource -> https://github.com/digicert/trustcore

lmz• 5 months ago

AGPLv3 so not exactly a drop in replacement, license-wise.

meinersbur• 5 months ago

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

reanimus2• 5 months ago

I don't know, I don't think it's really a huge waste of time considering I just read the entire comment thread in a handful of minutes. And beyond that, failing to comply with RFC requirements is the bug here -- a workaround existing for a specific language isn't a fix.

deng2• 5 months ago

Again: the maintainer does not say there is no bug. He says: please open a new issue, with a proper title and description for the actual underlying problem. Is that seriously too much to ask? Instead, the guy writes a whole blog post shitting on the project. Does anyone still wonder why people burn out on maintaining FOSS projects?

Alupis• 5 months ago

It's pretty standard to open a new issue and reference the previous issue for context, while keeping the new issue specific about what needs to be addressed - ie. RFC compliance.

I don't see the problem here at all - it was a reasonable request and it would have taken `feld` all of 2 minutes to do. Certainly less time than writing that blog post.

pseudohadamard4• 5 months ago

It's not entirely WolfSSL's fault. TLS 1.3 is a mass of kludges and hacks to deal with the fact that they created a new protocol that's nothing like TLS 1.0-1.2 but dressed it up to make it look like TLS 1.2. It even lies about its protocol version in the handshake, hiding the real version in one of the many extensions they had to invent to kludge it into working. And in terms of RFC compliance, one of the most widely-used implementations isn't compliant, it doesn't send any of the mandatory-to-implement cipher suites in its client hello which means unless you want to trigger a rehandshake on every single connect you have to implement their non-compliant form of TLS 1.3.

The real problem though is that they made a protocol that really, really wants to pretend it's TLS 1.2 when it really isn't anything like TLS 1.2. I wouldn't blame "middleboxes" for getting confused when they encounter that.

hypeatei2• 5 months ago

The maintainer should just open a new issue for RFC compliance himself since that's a pretty big issue and he obviously thinks OP spams too much.

This game of stalling / obfuscating via the issue tracker gets very old.

deng2• 5 months ago

The maintainer should just

Out of interest: which FOSS projects are you maintaining, and how many users do these have, approximately?

otterley4• 5 months ago

Why should that be the maintainer's burden?

toast02• 5 months ago

I can see both ways here.

If the maintainer just opens the concise bug report they want (RFC .... Section ... If TLS1.3 is negotiated and client sends session id, server must send cipherchangespec), they have what they want and can move on with their life.

However, if the maintainer can get the reporter to do it, the reporter has become a better reporter and the world has become a better place.

IMHO, the original bug report was pretty out there. Asking a library developer to debug a client they don't use with a sever they didn't write either is pretty demanding. I know openssl has a minimal server, I expect woflssl does too? that would be easier to debug.

Actually, on re-reading the original report, the reporter links to a discussion where they have all the RFC references. Had the reporter summarized that to begin with, rather than suggesting a whole lot of other stuff (like a different wolfssl issue that has to be completely unrelated), I think the issue would have gone better.

I will further add that putting a MUST in an appendix seems kind of poor editing. It should have been noted in section 4.1.2 and/or 4.1.3 that a non-empty legacy_session_id indicates that the server MUST send a cipher change spec. It's not totally obvious, but if the client requests middlebox compatability, the RFC says the server MUST do it. If the client doesn't request it by sending a legacy session id, the server can still send a superfluous change cipher spec message if it wants, although I don't know if it will help without the session id.

lelanthran• 5 months ago

The maintainer should just open a new issue for RFC compliance himself since that's a pretty big issue and he obviously thinks OP spams too much.

Reading the issue tracker, why would he do that unless he could repro?

Hi @feld , I can't really tell if this is related to the ticket that you pointed out. I'll be helping you with this issue as well as looking into the other ticket. Can you give me step by step instructions on how to reproduce what you are seeing? Please note that I have limitted experience with HAProxy and Erlang.
...
I've successfully connected to the server with the examples/client/client and I cannot reproduce what you are seeing. I've built with both WOLFSSL_TLS13_MIDDLEBOX_COMPAT defined and undefined.

He only gets a reply six months later!

This, I feel, clearly shows Feld's intentions - he wasn't interested in agetting it fixed, it was not a bug for him, but he was interested in spreading the word about it. i.e. To me, anyway, it looks like Feld is more interested in writing outrage-bait than getting a working product.

I've used WolfSSL in anger and the experience was much better than OpenSSL and AWS-lc.

Looking at the ticket itself, I consider the responses from the dev team to be pretty good support - better than some paid products I have used.

ablob• 5 months ago

The blog-poster wasn't happy with the issue being closed, so somehow I doubt that opening a new issue and referencing this one would've yielded a different result from what we got now.

Phemist• 5 months ago

This issue has a similar conversational rhythm that led to the AI agent hit piece that was trending yesterday:

https://theshamblog.com/an-ai-agent-published-a-hit-piece-on...

The OPs blog post also reeks of a similar style to the hit piece.

Given the large delay between the initial report and further responses by the user `feld`, I wonder if an OpenClaw agent was given free reign to try to clear up outstanding issues in some project, including handling the communication with the project maintainers?

Maybe I am getting too paranoid..

teekert• 5 months ago

A reasonable reply indeed from the maintainer, this happens a lot where you think together in an issue and identify whats really wrong near the end. Only then is one able to articulate an issue in a helpful, concise way. Perhaps GH could add a feature to facilitate this pattern.

SubjectToChange6• 5 months ago

Worse yet, despite publishing seventeen blog posts between filing the issue and finally responding to it, he has the gall to open with "Sorry I missed your replies (life gets busy)".

cookiengineer• 5 months ago

I was reading through the complete issue thread and I have to say I probably would side with the wolfSSL maintainers in part but they could have handled it in a nicer way.

"Anthu" only responded with this after "feld" asked why the issue was closed by them, and only then the response you mentioned was written.

"Anthu" could have simply asked before closing the issue and the reporter would have been fine. Like, say "So, this issue meanwhile evolved into RFC compliance and got a bit off track in my opinion. Can you please open up a separate issue for this so we can get this fixed in a more focused manner? That would be very helpful for our workflow. If not, I would open up an issue and reference this one if that's okay with you."

My point is that feld felt a little ignored in their problem, and the support role could have handled it a little nicer. I get that maintainer time is limited, but I would probably recommend an issue template for these matters where there's checkboxes in them like "keep it short, keep it reproducible" and maybe a separate issue template and tag for RFC matters.

On the other hand, "feld"'s blog post reaction was also quite trigger happy and in part in bad faith. They could've communicated the same things in a "non rage mode" after things have calmed down a bit.

YZF• 5 months ago

The author has spent a lot of time on this as well. I can see both sides. From the author's perspective their focus is their product/system. Any extra time they spend is not contributing to that. They've already spent a fair amount of time helping root cause the issue and from their perspective once it's clear what the issue is they're done. The author also seems to work on open source. In this case they are the customer of a product, granted an open source one, and they've helped the vendor (the maintainer) figure out something is broken. Their expectation is that the vendor takes things on from there and doesn't put up some bureaucracy.

That said ofcourse you paid nothing for this and you should expect nothing but the OSS project also has no expectations that their customers support them if those customers aren't getting their expectations met. In today's world one unhappy customer can give you a pretty bad rep, as is happening here. Now if you don't care then you don't care. But the argument that because your product is "free" then your customers have no voice doesn't sound that great either.

Everyone seems to be pointing how the author disappeared and came back much later. Well, they disappeared because it wasn't a problem or they've worked around it, and came back when they hit the problem again. Just like the maintainer doesn't work for the author the author doesn't work for the maintainer either.

It's also true the ticket now has a lot of history, but the original bug is still the same bug, it's just that now it has been root caused? The maintainer's response of now that you've found a setting that works around the issue you're good and we can close this also is a bit off. And sure, they don't work for anyone so they're welcome to do whatever they want.

As isn't uncommon when two humans communicate online there is some miscommunication here. But you can argue either way. Not being an open source maintainer I don't know what the "protocol" here is but the few times I've filed bugs against an open source product I did personally put in the extra mile to make them actionable. But in my day job I have to deal with all sorts of bug reports and chasing them down to a resolution is part of what makes the product I work on a better one. And yes, I get paid to do that ;)

johannes1234321• 5 months ago

What tis missing there is a support team and maybe a difference between a customer (user) facing support system and a big tracker.

Support guides the user through the discovery process, which can be messy and go circles, and the result of that is a big which is actionable by a developer.

dieulot• 5 months ago

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

stabbles• 5 months ago

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.

SubjectToChange6• 5 months ago

I don't see how OpenSSL can recover from it's 3.0 disaster. They would basically have to write off the past few years of development work and start over from version 1.1.1

ekidd• 5 months ago

I have systematically and successfully banned OpenSSL across all of my Rust projects. Sure, RusTLS shares a few C crypto primitives with OpenSSL forks. But I've never been happier with the overall library.

yencabulator2• 5 months ago

Rustls is great.

I think it's also worth pointing out that https://pkg.go.dev/crypto/tls has no OpenSSL in it.

germandiago• 5 months ago

Usability-wise (I do not need many features or compliance for FIPS) I have been happy with Botan: https://botan.randombit.net/

wink• 5 months ago

Can confirm, used Botan in the past and I didn't curse at it a lot. Certainly less than OpenSSL.

adev_• 5 months ago

I have been happy with Botan

Botan is under rated.

It is nowhere as optimized as OpenSSL but its APIs are one order of magnitude better to use.

The team behind also demonstrated a pretty serious handling of non-trivial issues like timing attacks.

SubjectToChange6• 5 months ago

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.

yjftsjthsd-h• 5 months ago

I don't think it's fair to judge the whole FreeBSD community by one person.

andrewflnr• 5 months ago

Seriously, where the hell did that come from?

SubjectToChange6• 5 months ago

Where did I judge the FreeBSD community?

mappu• 5 months ago

Go can create C ABI shared libraries, I think OpenSSL-compatible C bindings to Go's crypto/tls would be a really interesting option.

AtlasBarfed• 5 months ago

Do you want garbage collection in your SSL?

rurban• 5 months ago

Better than no memory safety, sure. Also a kernel should be memory safe, so garbage collected.

KingOfCoders• 5 months ago

Where do you see the problems? Because of memory that was not cleaned up and leaks secrets?

There the new runtime/secret could help.

jezek2• 5 months ago

Clearing of the secrets is a separate issue from memory allocation mechanism. It must be done all the way from the encryption layer to the program to avoid the leaks.

This is typically not done, only certain parts such as handling of the crypto keys. That's because it's pervasive and requires reworking everything with that in mind (TLS library, web framework, application).

On the other hand the centralization and global usage of GC in the process allows to modify it to always zero out the memory that it deallocated and to do GC at regular intervals so it can have advantage here (it's very easy to inadvertly leak the secrets to some string).

tialaramex5• 5 months ago

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.

vrighter2• 5 months ago

Never wondered why the camera app in your phone also uses this convention for filenames?

tialaramex5• 5 months ago

What convention? Is the problem here that you didn't realise this claimed to have been written either in December 2026 (ie months in our future) or, if you're willing to stomach a weird YYYY-DD-MM formatting - a mythical thirteenth month of the year?

The actual article was, eventually, updated to give a real date: Last updated on 2026-02-16

But originally it said 2026-12-13 and that's why I commented.

move-on-by2• 5 months ago

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.

Spivak• 5 months ago

Neither person is entitled to the work of the other and neither wants to do the work which seems to be how we ended up here. The author can't make demands of the project and so wrote a blog post warning others that it's not production ready and you'll have broken software if you use it. Their conclusion isn't that they must fix it but that you should use a more mature library.

Two adults both defected in the social prisoner's dilemma and so here we are. Both individuals believing to have done free labor for the other and that they should be grateful.

perching_aix7• 5 months ago

Oh yes, he has become a victim of using a FOSS library.

many such cases

randallsquared2• 5 months ago

The "victim" was the Elixir or Erlang library, not himself. To be clear.

move-on-by2• 5 months ago

I don’t think it was clear, but thanks for the insight.

Was WolfSSL forced upon Elixir or Erlang? Did they purchase it and received a defective product? Are they held hostage by WolfSSL’s decisions? Are they not allowed to modify WolfSSL as needed themselves?

I fail to see any victims beyond perhaps the WolfSSL maintainers for having to suffer such entitlement.

helpfulclippy• 5 months ago

What really gets me is the commenter at the end of the GH issue lecturing a maintainer on policy in their own tracker.

cryptonector• 5 months ago

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.

0xbadcafebee• 5 months ago

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.

tialaramex5• 5 months ago

No. This just underscored that if you don't encrypt stuff them idiots will break it. Notice that they didn't break any parts of TLS 1.2 which were encrypted, everything they broke is the unencrypted stuff, and so by encrypting more stuff (everything except client hello) in TLS 1.3 we improved that, and then by encrypting even more stuff in ECH (Encrypted Client Hello) we expect to improve it again.

Government regulation is good in that it can work, but it's terrible in that almost every other choice would be better if it works. For TLS 1.3 we made choices which work, if we'd waited for your hypothetical government intervention we'd still be using TLS 1.2 and Trump would presumably be collecting an inaugural "Super good Bank Encryption Champion" trophy from EDCO or somebody who fought against TLS 1.3 because it meant they'd have to actually do a good job.

snvzz• 5 months ago

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.

anthk2• 5 months ago

Dillo uses mbedTLS, it's fine.

1vuio0pswjnm7• 5 months ago

"OpenBSD was probably right. We just need to focus on LibreSSL and forget about all of these other libraries."

Having compiled many of the popular SSL libraries as an end user, on underpowered computers, IMHO LibreSSL has the best compilation process, e.g., least complex, fastest

The library doesn't have all the features of the others but being able to compile it relatively quickly and easily IMHO is itself a "feature"

WolfSSL has many, many options. Accepting the defaults is not sufficient IME.^1 According to the cited HAProxy blog post, AWS-LC is perhaps the fastest SSL library. But Amazon "overlooked" a simple CMake option that actually made it slower than WolfSSL

To summarise, (a) in addition to library "features" I think the compilation process is also important, (b) IME getting what one wants from the various SSL libraries, if even possible, is needlessly complex and (c) FWIW, LibreSSL has (IMO) the least complicated and fastest compilation process

1. It seems like the author did not want to spend the time to learn about all the options. For the end user (cf. "developer") this make sense. As the HAProxy blog post suggests, the SSL libraries that are controlled by people who work for advertising companies, e-commerce companies and CDN companies are naturally going to put their own interests first. Those interests may not always align with the end user's interests

WolfSSL sucks too, so now what?

Related Stories