Enable TLS 1.3 for libressl and boringssl libcryptos

[goatgoose]

Problem:

Now that TLS 1.3 is supported in libressl and boringssl, TLS 1.3 should be enabled when building with these libcryptos in s2n-tls. s2n-tls determines if the libcrypto has support for TLS 1.3 here:

s2n-tls/tls/s2n_tls13.c

Line 29 in 69cc503

bool s2n_is_tls13_fully_supported()

However, libressl and boringssl aren't enabled due to checks here:

s2n-tls/crypto/s2n_rsa_pss.h

Line 37 in 69cc503

#if RSA_PSS_SIGNING_SUPPORTED && OPENSSL_VERSION_NUMBER > 0x1010104fL

and here:

s2n-tls/crypto/s2n_rsa_signing.h

Line 25 in 69cc503

#if (S2N_OPENSSL_VERSION_AT_LEAST(1, 1, 1) || defined(OPENSSL_IS_AWSLC)) && !defined(LIBRESSL_VERSION_NUMBER) && !defined(OPENSSL_IS_BORINGSSL)

When s2n-tls is built with libressl, the openssl version number is set to the version of openssl when libressl first branched, and the libressl version number is ignored:

s2n-tls/crypto/s2n_openssl.h

Line 28 in 69cc503

#define OPENSSL_VERSION_NUMBER 0x1000107fL

This should likely be removed in favor of using LIBRESSL_VERSION_NUMBER directly whenever checking support for a feature.

Additionally, any changes needed to allow s2n-tls to use the TLS 1.3 features of libressl and boringssl should also be made.

Solution:

Enable TLS 1.3 when building with libressl and boringssl, and make any changes needed to use TLS 1.3 features properly with these libcryptos.

• Does this change what S2N sends over the wire? If yes, explain.
  • No
• Does this change any public APIs? If yes, explain.
  • No
• Which versions of TLS will this impact?
  • 1.3

Requirements / Acceptance Criteria:

When s2n-tls is built with libressl and boringssl, TLS 1.3 unit tests aren't skipped and succeed, and TLS 1.3 V2 integration tests succeed when re-enabled for these libcryptos.

• RFC links: Links to relevant RFC(s)
• Related Issues: Link any relevant issues
• Will the Usage Guide or other documentation need to be updated?
• Testing: How will this change be tested? Call out new integration tests, functional tests, or particularly interesting/important unit tests.
  • Will this change trigger SAW changes? Changes to the state machine, the s2n_handshake_io code that controls state transitions, the DRBG, or the corking/uncorking logic could trigger SAW failures.
  • Should this change be fuzz tested? Will it handle untrusted input? Create a separate issue to track the fuzzing work.

Out of scope:

Is there anything the solution will intentionally NOT address?