OpenSSL Dependency Removal

[stephenpdeos]

Problem

Opportunity: What are the needs of our target user groups?

More secure software. Currently, we use OpenSSL for consensus bits and there are concerns with the internal team continuing this utilization because of OpenSSL's track record (remote memory corruption bug in OpenSSL 3.0.4). The proposal is to instead switch over to use a submoduled-in static linked BoringSSL for consensus bits; i.e. anything in libchain.

Target audience: Who is the target audience and why?

Security/stability issues - applicable to full audience.

Strategic alignment: How does this problem align with our core strategic pillars?

Security/stability issue

Context

Competitors: Who are our top competitors (up to 5) and why? How do they solve this problem today?

Product differentiation: what would make our solution different?

Audience definition

Solution

Solution name: How should we refer to this product opportunity?

Open SSL Dependency Removal

Purpose: Define the product’s purpose briefly

Success definition: What are the top metrics for the product (up to 5) to define success?

Assumptions

Risks: What risks should be considered? https://www.svpg.com/four-big-risks/

Business Objectives/Functionality

Features/Epics

cleos

Reimplement HTTP requests via platform provided high level HTTP APIs. This would mean libcurl on Linux, NSURLSession on macOS, and WinHTTP on Windows. This actually has a number of nice benefits like getting cleos HTTP/2 support, system proxy support, ipv6 happy eyeballs, and not needing to deal with the CA store. The downside of course is that it's more code to maintain and different across platforms.

nodeos & keosd

My preference would be to eliminate TLS support in nodeos & keosd. I suspect usage of the HTTPS server in nodeos is extremely rare (some prominent community members regularly discourage its use, even). Likewise, I suspect connecting nodeos to keosd via TLS is extremely rare.

If we must keep TLS support in nodeos & keosd, perhaps look in to system provided TLS implementations such as GnuTLS and Core Transport.

Need to be mindful of eosnetworkfoundation/mandel#110 & #13 as they mix in to these decisions too. This effort is likely a blocker for #20.

Explore: Previously, as mentioned in the EOS PR above, boringssl's sha256 performance was rather poor. This is important to us. Performance testing with sha256 & r1 key recovery should be performed on the latest version before getting too far in to this change.

Tasks

Preview Give feedback

1. refactor cleos to use libcurl for HTTP/S AntelopeIO/leap#343
   OCI actionable enhancement 👍 lgtm +4
   
2. Replace OpenSSL usage with BoringSSL AntelopeIO/leap#644
   actionable 👍 lgtm +2
   

[stephenpdeos]

Temporarily deprioritized