[BOUNTY] Explore OpenSSL support in the TLS security transport

[Stebalien]

The need in brief

Currently, the SECIO transport supports using OpenSSL for the RSA . This can significantly improve performance as OpenSSL is highly optimized.

Now that we're switching to TLS, it would be nice to explore OpenSSL support in go-libp2p-tls.

Deliverable

1. A feature in go-libp2p-tls transport that enables OpenSSL support using go-openssl (behind an "openssl" build flag). See tls: support OpenSSL libp2p/go-libp2p#1539.
2. Any additional unit tests needed to ensure that this feature actually works.
3. Testground benchmarks comparing the OpenSSL implementation and the Go TLS implementation. Specifically, the benchmarks must compare:
   • Handshake latency.
   • Handshake throughput (how many handshakes can we complete in N second).
   • Connection latency (ping time).
   • Connection throughput.

Requirements

• This feature must be interoperable with go-libp2p's and rust-libp2p's current TLS transports.
• This feature must implement the libp2p TLS handshake as defined in the spec.

Non-requirement: While the described feature should be as fast as possible, it may not have higher overall throughput than go's built in TLS implementation, due to CGO overhead. If that turns out to be the case, but it looks like OpenSSL's handshake throughput is significantly higher than Go's, we may create an additional bounty to use OpenSSL for the handshake only.

Guidelines

• Please use the IPFS Go Contributing Guidelines as your north star — adherence to these guidelines are crucial when it comes to awarding a potential bounty!
• Please DO NOT bundle a general code refactor with the completion of this bounty!

[RubenKelevra]

One might argue, that OpenSSL is quite a 'fat' library with a lot of code for compability reasons and without a good security record.

Libsodum might be a better alternative to look into. It's well maintained, actively developed by cryptographers, is portable but also highly optimized and is one order of magnitude smaller than OpenSSL.

It's also the reference implementation of Curve25519, ChaCha and Salsa20 - which we both probably ending up using anyway.

[Stebalien]

OpenSSL has wide support on many platforms and has now received quite a bit of attention from the security community. Libsodium support would also be welcome but should be tackled independently.

[RubenKelevra]

I think the most compelling argument for using libsodium is, the ability to use salsa2012 (salsa with just 12 rounds instead of 20). This allows getting quite decent performance even on embedded systems - like routers.

Just a number off my head - A 74K MIPS32 with ~540 MHz does around 22 MBit/s with salsa2012 and umac - while aes128 with gcm does 4 MBit/s.

[Stebalien]

@RubenKelevra please open a new issue for new feature requests.

[Geo25rey]

@Stebalien Just to confirm, a small amount of work if any is required on go-ipfs itself, but libp2p/go-libp2p-tls needs to be worked on? All I could imagine changing in go-ipfs is in the Makefile by adding the "openssl" tag.

[Stebalien]

Nothing is required in go-ipfs, as far as I know. As long as building go-ipfs with GOTAGS=openssl causes TLS to use openssl internally, this is fixed.

[Geo25rey]

Alrighty. Here's a bit of a status update. I've taken over libp2p/go-libp2p-tls#67 and currently have a draft PR opened (libp2p/go-libp2p-tls#71) appending to @balajijinnah's work. Before that can get merged, libp2p/go-openssl#13 needs to get merged to conform to the libp2p spec. I'm also working on adding tests in libp2p/go-libp2p-tls#71, but it's hard to tell if tests fail due to not using TLS 1.3 or if there are bugs in the PR itself.

[gammazero]

This appears top have been done here: libp2p/go-libp2p-tls#72.

Currently there is no plan for further exploration of OpenSSL for TLS.