What's new

Discussion - OpenSSL 1.1.1 and beyond

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

cmkelley

Very Senior Member
I was having a thought about OpenSSL 1.1.1 and started the below as a response in a different thread, but I realize it's grown wildly off-topic for that thread. This is just a discussion point and a request for someone with more understanding than I to chime in as to if I'm on the right track or completely off the rails.

** IF ** I understand the situation correctly, and I very well may not, we'll never see OpenSSL 1.1.1 in a router that is being sold today. At some point in the future, with an as-yet-unreleased SoC, the SDK for that SoC might ship with a Kernel and userland that includes OpenSSL 1.1.1. But the chance of the SoC manufacturer updating existing SDKs for this seems wildly unlikely, and could wreck havoc on Entware, because there would be two fundamentally different kernels (and therefore APIs and other structures) for the same SoC - ensuring the user got the correct version would be challenging at best.

Bottom line, I believe we are stuck with the current situation where people who know what they're doing produce binaries that are statically linked against 1.1.1 (e.g. kvic's pixelserver-tls betas) or other libraries that can't be updated because they are tied into the SDK.

Big picture, this is starting to move beyond the intended use of a consumer-grade router. When stuff like OpenSSL 1.1.1 becomes very important to you, perhaps it's time to think of using perhaps a NUC or something similar running pfSense rather than a consumer-grade router. If you have to know-how to need and use stuff like OpenSSL 1.1.1, you've more than likely got the know-how to set up a pfSense solution. Statically linked binaries will, I'm fairly certain, take more memory, and even though swap files can be used, it's possible to run out of room for everything that has to be kept in memory if large numbers of programs start to be statically linked against never version libraries.

Don't get me wrong, it's crazy wonderful that RMerlin, kvic, thelonelycoder, Jack Yaz, Adamm, etc. are able to wring so much out of what is fundamentally a very simple system. And I'm very thankful for their efforts. And, I'm going to keep using my AC86U for either as long as it holds out, or until there becomes a very compelling reason to need something at the router level that the SDK doesn't support and can't be hacked on by someone with that knowledge.
 
Openssl 1.0.2 will be supported until next year. I think all manufacturer have to move to 1.1.1 LTS.
 
Openssl 1.0.2 will be supported until next year. I think all manufacturer have to move to 1.1.1 LTS.
Right, security fixes only through the end of 2019.

"They" will have to move to 1.1.1 LTS if they want continued bug and security fixes, true. But I believe "they" aren't the router manufacturers such as ASUS, but rather the SoC manufacturers such as Broadcom, since they provide the SDKs the router manufacturers have to use to for the SoC. That's why I said a future SoC someday may support 1.1.1, but Broadcom, et al. have zero incentive to go back and provide updated SDKs for existing SoCs. In fact, they have a distinct dis-incentive to do so, it would cut into sales of newer SoCs.
 
Asus can upgrade to OpenSSL 1.1.1 if they wish so, they don't need Broadcom for this. They've already done a 1.0.0 to 1.0.2 upgrade a few years ago. That one component that didn't work properly with 1.0.2 (Beceem) is linked against a separate 1.0.0 OpenSSL library. And in IPSEC's case on the 64-bit HND kernel, Strongswan is statically linked against a 64-bit OpenSSL 1.0.2.

All I can tell is they are aware of the incoming end of life for 1.0.2.
 
Asus can upgrade to OpenSSL 1.1.1 if they wish so, they don't need Broadcom for this. They've already done a 1.0.0 to 1.0.2 upgrade a few years ago. That one component that didn't work properly with 1.0.2 (Beceem) is linked against a separate 1.0.0 OpenSSL library. And in IPSEC's case on the 64-bit HND kernel, Strongswan is statically linked against a 64-bit OpenSSL 1.0.2.

All I can tell is they are aware of the incoming end of life for 1.0.2.
Good to know. I thought SSL was far more integrated into the kernel/system than your post would indicate. Am I correct in thinking it's not something you could even attempt (ignoring the time cost for the moment) due to the binary blobs requiring it?
 
How hard is it to create statically linked binaries?

I would like to have (/build) a version of unbound with OpenSSL 1.1.1 statically linked, so I can use name verification in unbound.
 
Am I correct in thinking it's not something you could even attempt (ignoring the time cost for the moment) due to the binary blobs requiring it?

Replacing is impossible due to the closed source portions of the code that are relying on the 1.0.2 API. Adding in parallel is possible, but would add around 3 MB to the firmware size just for the sake of having OpenVPN and httpd use OpenSSL 1.1.1. Third party software like pixelts would not be able to easily use it, since the library would need to be under a different name to ensure that 1.0.2 remains the default library used by the rest of the firmware., so overall it would make little sense.

How hard is it to create statically linked binaries?

That depends on the program you are trying to statically link. Some have configure time switches, others might require modifying the build recipes.
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top