What really gets me is the commenter at the end of the GH issue lecturing a maintainer on policy in their own tracker.
WolfSSL sucks too, so now what?
81–90 of 136 posts
Re: WolfSSL sucks too, so now what?
#82Re: WolfSSL sucks too, so now what?
#83There is also s2n-tls. I'm working on a GSS-based interface to TLS, much like SChannel is an SSPI-based interface to TLS.
Re: WolfSSL sucks too, so now what?
#84This 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…
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.
> 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.
Re: WolfSSL sucks too, so now what?
#85Usability-wise (I do not need many features or compliance for FIPS) I have been happy with Botan: https://botan.randombit.net/
> 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.
Re: WolfSSL sucks too, so now what?
#86This 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…
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.
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.
Re: WolfSSL sucks too, so now what?
#87There’s always rustls.
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 :-(
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
Re: WolfSSL sucks too, so now what?
#88This 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…
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 ;)
Re: WolfSSL sucks too, so now what?
#89If 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.
Re: WolfSSL sucks too, so now what?
#90This 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…
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.
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.