WolfSSL sucks too, so now what?

Alternative TLS Libraries Discussed

• Multiple alternatives are suggested: rustls, BearSSL, MbedTLS, NanoSSL, Botan, s2n‑tls, LibreSSL, and AWS-LC-backed setups.
• BearSSL is praised for design and smallness, but concerns are raised: last release in 2018, beta label, no TLS 1.3, and minimal recent development.
• MbedTLS is viewed as working well in lightweight clients (e.g., Dillo), but someone recalls historically frequent API breakage.
• NanoSSL (DigiCert) is open source but AGPLv3, so problematic as a drop‑in replacement for many projects.
• Botan is described as pleasant to use, with good handling of timing-attack issues, though not as optimized as OpenSSL.
• LibreSSL is defended as a solid OpenSSL drop‑in, especially given OpenBSD’s use; blame is placed on distros for not adopting it.
• Some note that projects that tried to move away from OpenSSL often came back, invoking the “just use OpenSSL” meme.

rustls and Crypto Backends

• rustls is suggested repeatedly; there’s a C FFI and a FIPS-compliance mode when used with AWS‑LC.
• rustls doesn’t implement primitives itself; it relies on providers like AWS‑LC, Ring, or RustCrypto.
• One thread notes this seems to conflict with the blog’s criticism of AWS‑LC/BoringSSL, but others argue:
  • The criticisms were about TLS stacks and vendor focus, not the low‑level primitives.
  • Using their vetted C/assembly crypto under a safer Rust protocol/X.509 layer is a good compromise.

WolfSSL Issue, RFC Compliance, and Maintainer–User Conflict

• The GitHub issue at the center of the blog is dissected:
  • Some argue the blog author acted in bad faith: long periods of silence, then a critical post instead of opening the narrower RFC‑compliance ticket requested by the maintainer.
  • Others say asking the reporter to refile was needless bureaucracy, especially once the underlying spec violation was understood; the maintainer could have opened the focused ticket themselves.
• Several commenters praise wolfSSL’s responsiveness and support quality; others note the tone could have been more diplomatic and suggest better templates or separation between “support” and “bug tracker.”
• Broader debate emerges over “entitlement” in FOSS:
  • One side: maintainers don’t owe unpaid labor; users are not customers unless they pay.
  • Other side: users reasonably judge projects by how they handle bug reports; “it’s free” doesn’t make criticism illegitimate.
  • Some report similar experiences: they’ll warn others off software whose maintainers seem overwhelmed or unresponsive, without anger—just risk management.

TLS 1.3, Middleboxes, and Standards

• The concrete technical issue involves TLS 1.3 “middlebox compatibility” behavior and RFC “MUST” requirements.
• Some contend wolfSSL’s behavior is non‑compliant and that a language‑specific workaround isn’t a fix.
• Others emphasize that TLS 1.3 itself is messy:
  • It masquerades as TLS 1.2, hides the real version in extensions, and includes hacks for legacy middleboxes.
  • A widely used implementation is itself non‑compliant with mandatory cipher requirements, forcing others to follow de facto behavior.
• One commenter argues this shows standards are weakened by catering to broken middleboxes and calls for software regulation and “building codes.”
• A counter‑view defends the protocol evolution: middleboxes only broke unencrypted parts; TLS 1.3 and ECH progressively encrypt more, which is seen as a pragmatic, effective alternative to government intervention.

Other Ideas and Side Threads

• Suggestion to wrap Go’s crypto/tls behind an OpenSSL‑compatible C ABI; objections focus on adding GC to the TLS stack vs C’s lack of memory safety.
• Some humor about “just write your own” TLS in the age of advanced AI coding tools, acknowledged implicitly as unrealistic.
• Mention that HAProxy now ships “performance” packages built with AWS‑LC, illustrating how large projects are gravitating toward vendor‑backed crypto libraries despite philosophical concerns.