WolfSSL Doesn't Suck

My previous post made some rounds on the internet. However, there has been a happy ending to this saga. I've revisited my test environment as their requirement of building the library with WOLFSSL_TLS13_MIDDLEBOX_COMPAT and still not seeing any changes in behavior was bothering me. I took a fresh stab at this again and discovered a problem that was causing the correctly built WolfSSL package to not be the one which was installed. It is a little annoying that there's no way to easily verify the build flags etc of the WolfSSL library (no helper program/binary which displays this in some useful --help or other flag), but I fully take the blame for screwing that one up.

I've had some more back-and-forth with a WolfSSL dev and they've chased this problem further. They're adding an extra check for compliance as well as some tests. This is good.

What's not so good is that this feature is still gated behind defining a CFLAG that most people probably won't even know exists. They already have --enable-tls13 and --enable-tls13-draft18 configure args, so perhaps I can convince them to document this more thoroughly or even add it as another arg.

WolfSSL is extremely configurable. Maybe even too configurable for its own good. That is probably the nature of things when you are also targeting very tiny embedded environments and want them to have a modern crypto library. I've already run into other things before, like needing WOLFSSL_GETRANDOM so it works in a chroot where there is no /dev. WolfSSL might very well be the Lego of TLS libraries, and clearly I'm just not old enough (or smart enough) to play with a set that has this many pieces.

Perhaps WolfSSL really is the OpenSSL replacement we need. Just be aware that it's not as "drop-in" of a replacement as you'd think. You still need to know how to hold it right.

Steve would be proud.