6 ms·
WolfSSL sucks too, so now what?
- ospray 8mo agoWe need something with TLS in the name for the next one so people stop getting confused.
- magicalhippo 8mo agoMbedTLS[1] got your back! [1]: https://www.trustedfirmware.org/projects/mbed-tls/ https://www.trustedfirmware.org/projects/mbed-tls/
- anthk 8mo agoThat's being used by Dillo and it's working really well even on legacy computers.
- weinzierl 8mo agorustls is there. It has TLS in the name, it is good and there is a C FFI wrapper.
- gspr 8mo agoRustls 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-chan 8mo agothere is https://github.com/RustCrypto/rustls-rustcrypto https://github.com/RustCrypto/rustls-rustcrypto fwiw
- gspr 8mo agoIt's a great effort, but it's far from usable: > USE THIS AT YOUR OWN RISK! DO NOT USE THIS IN PRODUCTION
- PunchyHamster 8mo agoThe author also doesn't specify what that even means and what problems it causes
- tialaramex 8mo agoThe primitives aren't a problem. You can't write them in any vaguely modern high level language. And when I say "High level" I mean that the way K&R does when they describe their new C programming language as high level. The reason you can't write cryptographic primitives in a high level language is that optimising compilers love clever tricks which offer data dependent performance, across every layer of their design - but in cryptography we want constant execution time regardless of either the plaintext or keys used. 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.
- LoganDark 8mo agoWhat? Ring is not even close to a fork of BoringSSL; it merely borrows subroutines from BoringSSL.
- gspr 8mo agoOk, maybe not a fork outright. But the project description says: Most of the C and assembly language code in ring comes from BoringSSL.
- toast0 8mo agoThat's the proper way to use OpenSSL and derivatives. Their C and assembly code for crypto primatives is good. Protocol code and x.509 certficate handling will probably be better written in another language.
- yencabulator 8mo agoYou might like https://github.com/ctz/graviola/ https://github.com/ctz/graviola/ 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.
- koakuma-chan 8mo agorustls doesn't have its own implementation of cryptography, you have to choose a provider like openssl or aws lc
- SAI_Peregrinus 8mo agoOr rustcrypto. Rustls is a TLS layer that can wrap any cryptography layer providing the necessary primitives.
- brianpane 8mo agoThere is a rustls side project called Graviola that's building a fast crypto provider in Rust+ASM. It's taken an interesting approach: starting with an assembly library that's been formally proven correct, and then programmatically translating that into Rust with inline assembly that's easy to build with Rust tooling.
- dwedge 8mo agoA c wrapper to rust feels like we've gone full circle
- pocksuppet 8mo agoThat would be amazing and really cement the proven value of Rust.
- tialaramex 8mo agoThere's even a project for a deliberately OpenSSL drop-in compatible Rustls backed library. It is intended for specific projects because OpenSSL is sprawling and they don't implement most if it, but in principle if you use the same parts of OpenSSL your C likely works with this safer + faster alternative today, why not recommend it to your users. https://github.com/rustls/rustls-openssl-compat https://github.com/rustls/rustls-openssl-compat
- zephen 8mo agoYou're obviously looking for lastLs.
- account42 8mo agoBut then how will we spot the pedants.
- MrBuddyCasino 8mo agoNow what? BearSSL.
- kevin_thibedeau 8mo agoMbedTLS
- aidenn0 8mo agoI don't know if it's still the case, but MbetTLS used to change its API as often as I change my socks.
- mythz 8mo agoBearSSL 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 https://bearssl.org
- jorams 8mo agoBearSSL 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 8mo agoWhere is Bellard when we need him?
- mananaysiempre 8mo agoMost relevantly here, selling a commercial implementation of ASN.1: https://bellard.org/ffasn1/ https://bellard.org/ffasn1/.
- eptcyka 8mo agoThere’s always rustls.
- LtWorf 8mo agoFIPS compliant?
- eptcyka 8mo agoIt is if you use the FIPS compliance feature - then you also depend on aws-lc, but only for the crypto primitives.
- gspr 8mo agoRustls 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 :-(
- fulafel 8mo agoFrom 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
- gspr 8mo agoMy point is that the article this thread is attached to starts out with how BoringSSL and AWS-LC won't cut it. And when rustls is suggested as an alternative, it's important to point out that it requires precisely those two (either one of them).
- saqrais 8mo agoNanoSSL by DigiCert https://dev.digicert.com/trustcore-sdk/nanossl.html https://dev.digicert.com/trustcore-sdk/nanossl.html It's opensource -> https://github.com/digicert/trustcore https://github.com/digicert/trustcore
- lmz 8mo agoAGPLv3 so not exactly a drop in replacement, license-wise.
- meinersbur 8mo agoThis 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 https://github.com/wolfSSL/wolfssl/issues/9156
- reanimus 8mo agoI 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.
- deng 8mo agoAgain: 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?
- halapro 8mo agoNot great behavior I agree, but what else is there to say other than "it does not match the spec at point 1.2.3"?
- dieulot 8mo agoRegarding HAProxy, they ended up using AWS-LC in their new Debian/Ubuntu “performance” packages: https://www.haproxy.com/blog/fresh-from-aws-reinvent-supercharging-haproxy-community-with-aws-lc-performance-packages https://www.haproxy.com/blog/fresh-from-aws-reinvent-superch...
- stabbles 8mo agoMany 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.
- SubjectToChange 8mo agoI 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 8mo agoI 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.
- yencabulator 8mo agoRustls is great. I think it's also worth pointing out that https://pkg.go.dev/crypto/tls https://pkg.go.dev/crypto/tls has no OpenSSL in it.
- germandiago 8mo agoUsability-wise (I do not need many features or compliance for FIPS) I have been happy with Botan: https://botan.randombit.net/ https://botan.randombit.net/
- wink 8mo agoCan confirm, used Botan in the past and I didn't curse at it a lot. Certainly less than OpenSSL.
- adev_ 8mo 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.
- SubjectToChange 8mo agoThe 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 8mo agoI don't think it's fair to judge the whole FreeBSD community by one person.
- andrewflnr 8mo agoSeriously, where the hell did that come from?
- SubjectToChange 8mo agoWhere did I judge the FreeBSD community?
- perching_aix 8mo agoProbably where you said: > If this is what the FreeBSD community is like, I want nothing to do with them.
- SubjectToChange 8mo ago>If “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.
- 8mo ago
- deleted 8mo ago[deleted]
- mappu 8mo agoGo can create C ABI shared libraries, I think OpenSSL-compatible C bindings to Go's crypto/tls would be a really interesting option.
- AtlasBarfed 8mo agoDo you want garbage collection in your SSL?
- rurban 8mo agoBetter than no memory safety, sure. Also a kernel should be memory safe, so garbage collected.
- codys 8mo agoGarbage collection is not required for memory safety. Languages that have garbage collection are not all memory safe.
- KingOfCoders 8mo agoWhere do you see the problems? Because of memory that was not cleaned up and leaks secrets? There the new runtime/secret could help.
- jezek2 8mo agoClearing 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).
- tialaramex 8mo 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.
- vrighter 8mo agoNever wondered why the camera app in your phone also uses this convention for filenames?
- tialaramex 8mo agoWhat 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.
- vrighter 8mo agoI am an idiot. I did not notice the date was in the future
- deleted 8mo ago[deleted]
- phendrenad2 8mo ago[flagged]
- move-on-by 8mo 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 8mo agoNeither 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_aix 8mo ago> Oh yes, he has become a victim of using a FOSS library. many such cases
- randallsquared 8mo agoThe "victim" was the Elixir or Erlang library, not himself. To be clear.
- move-on-by 8mo agoI 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.
- 8mo ago
- helpfulclippy 8mo agoWhat really gets me is the commenter at the end of the GH issue lecturing a maintainer on policy in their own tracker.
- cryptonector 8mo agoThere 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 8mo agoIf 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.
- tialaramex 8mo agoNo. 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 8mo agoNothing 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.
- anthk 8mo agoDillo uses mbedTLS, it's fine.
- 1vuio0pswjnm7 8mo 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