Why return to Mbed TLS?

Mbed TLS Does not support TLS 1.3
wolfSSL Supports TLS 1.3

I just don't quite understand. Are sites for example in the browser no longer working on TLS 1.3 or what changes this transition ?

Here's some of the discussion: https://openwrt.org/meetings/20221130#cryptographic_library More in other meeting minutes.

I get the feeling (from reading the commits when the change was made) that the slow release schedule and unstable ABI of WolfSSL were the primary culprits.


So maybe better to replace MbedTLS with wolfSSL in assembly for security?
It seemed to work fine, there were no problems, at least for me. I just didn’t understand that now only TLS 2.0 will work, for example, from a computer, from a browser, I went to a website or it’s only for a router, but it doesn’t affect all other devices.

But it may have seemed to me that it became better to work on the new version, I still don’t understand, but everything started to open up quickly

WolfSSL has disqualified itself over the last release cycle with its ABI changes coming with important security updates (it also hasn't really shone in terms of functionality bugs either), but it's still available (just not as default) - if you care about it.

With OpenWrt's hostapd now supporting MbedTLS (it's not merged upstream yet), there now is a viable alternative for the primary reason of shipping a tls provider, supporting WPA3. On the pro side, it's smaller than WolfSSL or OpenSSL - and its ABI is predictable within a release cycle.

If you're looking for features, OpenSSL is always king - but also the largest among the the three; ABI stability is also managed well.


OpenWrt is looking at the choice of default between Wolf vs mbed vs Open as a choice about the primitives being used for hostapd/wpad and not very many users use authentication modes that make use of TLS.

Whichever default is used, you can still have other libraries on your system for use with your web server, or client (wget/curl) utilities so they can have access to TLS 1.3.

That's unfortunate. I still use it on my devices because of the available hardware AES acceleration on Intel and ARM CPUs. I hope at some point we can go back to WolfSSL as default for this reason, if nothing else.

At the current time it would be (relatively-) more likely to move to OpenSSL (although that would kill off all 8 MB flash devices), than to WolfSSL again (OpenSSL was strong in the running to replace WolfSSL, before MbedTLS became an option); OpenSSL supports crypto extensions as well.

The imagebuilder already provides you with quite some freedoms to pick your favourite tls provider (ustream and wpad are built for all three alternatives), curl (libcurl) is one of the few (main) packages that forces a build time decision (but at build time, you can configure 'everything').

1 Like

Related https://github.com/openwrt/openwrt/issues/12874


All that I understood from the above is that it is connected with wi-fi, for me the simpler the better.
There were problems on some devices, they didn’t want to connect, and if wpad-basic-mbedtls solves problems, then I’m all for.

And what does libustream-mbedtls do, is it also only for wi-fi ?

And if you stop supporting routers with 8 MB of flash memory, then more than half of the people will simply go into the fog :slight_smile:

Just LuCI to support https.
x86 without wifi:

$ opkg whatdepends libustream-mbedtls
Root set:
What depends on root set
        luci-ssl git-23.035.26083-7550ad6       depends on libustream-mbedtls20201210

RT3200 with wifi:

$ opkg whatdepends libustream-wolfssl20201210
Root set:
What depends on root set
        luci-ssl git-20.244.36115-e10f954       depends on libustream-wolfssl20201210


Yeah, that would be bad. It would be nice if mbedtls version could be rolled up to v 3.0, as mentioned on the issue that @ynezz posted above.

does MbedTLS support hardware acceleration?
I have been unable to use WolfSSH with hardware acceleration on because WIFI stops working. If I build it without hardware acceleration it works fine.

No, if you want that, look into openssl or wolfssl (in that order), which do.

1 Like

Hear hear. Good riddance, I say.

1 Like

@fkl7834456 I'm responsible for it. The reason is fairly simple:

wolfSSL was switched to away from mbedTLS because of no hostapd support. When hostapd gained mbedTLS support, the default was switched back.

wolfSSL has been causing all kinds of problems. mbedTLS OTOH does not support TLS 1.3. The way forward IMO is to update mbedTLS to a newer version with TLS 1.3 support.


And which one to choose for a 8/64 MB device?

does it matter?

For size reasons alone, you'd want mbedtls - everything else being secondary on 8 MB flash.

Only if you really want/ need additional features, you may need to look into wolfssl or openssl, but then you really need to look into the details.

1 Like

Most devices with OpenWrt are of those capabilities.

One interesting OpenWRT detail is that by default it ships with PPP support enabled and disabling it provides valuable extra space that can be used for other means like wolfssl or openssl.
I would argue that PPP less used today that it was 10 years ago and should be specifically enabled instead of being selected by default. this would put less pressure on 8mb devices.

I'm on fiber, and I need PPPoE. So you're mistaken. Just because you don't need or see it doesn't mean it's gone - or rare. Quite the contrary.