WolfSSL sucks too, so now what?(blog.feld.me) |
WolfSSL sucks too, so now what?(blog.feld.me) |
> 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.
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.
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.
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 ;)
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.
This game of stalling / obfuscating via the issue tracker gets very old.
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.
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.
Out of interest: which FOSS projects are you maintaining, and how many users do these have, approximately?
"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.
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..
>...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.
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.
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.
many such cases
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.
The state of things sucks :-(
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.
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.
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.
I think it's also worth pointing out that https://pkg.go.dev/crypto/tls has no OpenSSL in it.
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.
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
The state of things sucks :-(
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
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).
There the new runtime/secret could help.
Yeah, no, I can't find a way to read this in which it's not in the future.
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.
It's opensource -> https://github.com/digicert/trustcore
> Was WolfSSL forced upon Elixir or Erlang?
Yes actually, and upon others, that's how computer networking works. Did you read the blogpost by the way? Even just the beginning? Really doesn't seem like it.
Hint: there's a reason the word "middlebox" is mentioned 16 times in there, and that the word "server" is mentioned another 6 more.
> Did they purchase it and received a defective product?
They did not purchase a copy, WolfSSL distributed them one for free. The blogpost author did identify the product as defective however, as it allows for and defaults to spec-noncompliant behavior. It stands to reason that this then affects WolfSSL's paying customers (and their downstream customers) too, who might be unknowingly operating or interacting with spec-noncompliant services as a result.
Will people need to read out the whole article for you?
> Are they held hostage by WolfSSL’s decisions?
Yes, and so are others, that's (still) how computer networking works.
> Are they not allowed to modify WolfSSL as needed themselves?
What would they do with it? Put it on a USB stick and stick it up their ass?
> for having to suffer such entitlement
Are you really one to take issue with another person's behavior after this power tantrum?
I did not notice the date was in the future
Languages that have garbage collection are not all memory safe.
The problem isn't really the port used, it's the uncanny-valley approach they took in creating something that looks like a creepy zombie version of TLS 1.2, which keep-suspicious-things-out appliances quite rightly get suspicious over.
I've seen a ton of this recently as Amazon has the option for TLS 1.3 with post quantum encryption on cloudfront now. A whole ton of different middleware shits itself.
I certainly understand the maintainer here, because that’s what I keep telling colleagues at work.
Tickets get really cumbersome if they are not clear and actionable.
For both of them! Since both of them are aware now, either one could open that ticket. If the maintainer has very specific ideas about how a ticket should look, maybe they can do that themselves quickly, now that they are aware of not complying with the RFC. Then the ticket will perfectly match their expectations.
wolfSSL also sells commercial licenses so it's not like they're going uncompensated for their work. Regardless, we shouldn't put people on pedestals because their title is "FOSS maintainer"
You are especially not entitled to bullying maintainers as has been unfortunately the standard in infosec.
Open source is not about you.
https://gist.github.com/richhickey/1563cddea1002958f96e7ba95...
IMO more projects have to explicitly state this for example in a terms document, like https://github.com/mhoye/maintenance-terms/blob/main/MAINTEN...
You know a social movement went full circle when a criticism that is so scathing, you couldn't have possibly come up with it and make it trend before, even if you gave it your all, is now a motto and a point of pride for those who follow it.
This is happening at the same time where hundreds of millions of regular variety consumers are being fed propaganda daily about how it's "finally time to switch to Linux", because it's so much better for them, the individual. If only they knew it's apparently not actually about them, never has been, and never will be.
Presumably, the user wants the best for the product and their ability to use the product. So they have a definite interest in documenting a todo list.
It doesn't make sense for the two to be at war with each other. It is no big deal for the maintainer to ask a favor. It's not too big of a deal for the user to decline. There's no need to attack.
I have often dropped a note to the maintainer of a project I bumped into. I'm sure they would prefer a bug report in their official forge. But I don't really use their software except for this one time. I'm not willing to jump through the hoops to create an account in yet another SaaS just to file this one report. Just dropping them an email was a courtesy. But often they don't interpret it that way. I'm perfectly un-insulted if they just delete my note and never "fix" the issue because it didn't come through proper channels.
No attacks. No war. Just well wishes. But I might very likely avoid the product if I'm ever back in those woods. Not out of anger or retribution. Just because I'll remember that the product had at least one sharp edge for my use case and the maintainer was a bit overwhelmed by the weight of supporting my niche use case. That doesn't make the maintainer a bad person or even a bad maintainer.
If they don't want to, that's certainly their right, but it also tells us something about that project.
The problem with OpenSSL isn't these cryptographic primitives, that's why you will see basically the same primitives re-used in lots of different places. It's like finding out that the guy who was just arrested for murder also eats pizza. Yeah, people do that. The problem wasn't the pizza, it was the murder. OpenSSL's implementation of the AES cipher isn't broken, the problem is elsewhere.
Also, even if rustls is using aws-lc-rs, you still get the TLS parts from the rustls project, and aws-lc-rs is just lower-level crypto. That means there's less places for Amazon to say no; they either implement an algorithm or don't.
> USE THIS AT YOUR OWN RISK! DO NOT USE THIS IN PRODUCTION
Protocol code and x.509 certficate handling will probably be better written in another language.
> If this is what the FreeBSD community is like, I want nothing to do with them.
“If you break the law, then you go to jail” is not “you broke the law, you are going to jail”. I didn’t judge the entire FreeBSD community based on this blog post.
Where did they say you did?
Of course I wouldn't have been able to come up with this statement because the perverted view of OSS devs owing free work to the users of their software was not so pervaisive.
On your edit: a bit rich saying the calls for switching to Linux propaganda, especially with the downturn of UX of windows and macos... Also why just hundreds of millions.. Go for hundreds of billions if you're just going to pull out numbers. Apart from that - even if Linux is not about the users, it is in many cases better for them as-is. Funny how that works with no conflict.
"Exactly"? I'm afraid that's not a very physically sound request. But let's say, prior to 2026-02-14T03:46:03Z then. I hope that suffices.
> Of course I wouldn't have been able to come up with this statement
That would make sense, because you specifically I never expected to: https://en.wikipedia.org/wiki/Generic_you
> Also why just hundreds of millions.. Go for hundreds of billions if you're just going to pull out numbers
You see, that would be because I did not just pull out an arbitrary number. "How many Windows users there are" is a reported fact you can just search for, and even the total is not "billions" (plural). I know, I was surprised too. From the horse's mouth: https://blogs.windows.com/windowsexperience/2025/06/24/stay-...
>Where did they say you did?
They said it in the part where you got all confused and responded to me.
What you originally responded to above:
> I don't think it's fair to judge the whole FreeBSD community by one person.
So they just like, gave us a fun fact, right?
Conversely, I was also apparently just speculating:
> Probably where you said
So many things are possible when we don't want to be found wrong. Including pretending that figurative speech only exists when it's convenient.
Otherwise, I really don't see what would be so hard in understanding why throwing an "if" at the start would still lead to people taking what you said the way they did.
For the record, contrary to your assertion, even your example is affected by this:
> If you break the law, then you go to jail
If you posted this (and even only just this) under a random thread, people would think you're accusing someone (whoever the given thread is most about) to be somehow guilty of some untold crimes and/or that some chatbot got loose. I hope you can appreciate how people would be absolutely correct to think that way.
Volunteering to maintain a project literally does create entail accepting duties, that's what taking on the role of maintainer entails. They are of course free to give up that role at any time, but those duties exist while that role has been adopted.
You can't really say someone has a "duty" without also implying that they have a "responsibility," and thus liability if they fail to execute those duties properly. I don't see how this fits at all for a volunteer. Very few people are going to volunteer for no pay if they're taking on a risk of liability.
Maybe you mean a civic duty? That would make somewhat more sense, but the problem is that there’s no objective standard against which to test performance. It’s completely subjective and will be forever argued—much like this thread. :-)