ci: sslyze dependency issues

Security issue notifications

If you discover a potential security issue in s2n we ask that you notify AWS Security via our vulnerability reporting page. Please do not create a public github issue.

Problem:

SSLyze relies on nassl. While trying to install sslyze<3.0.0, there are no aarch64 artifacts on Pypi for nassl.

Building nassl 2.2.0 from source fails with:

gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-sw$tches -moutline-atomics -D_GNU_SOURCE -fPIC -fwrapv -fPIC -DLEGACY_OPENSSL=1 -I/tmp/nassl-2.2.0/deps/openssl-OpenSSL_1_0_2e/include -Inassl/_nassl -I/usr/include/python3.7m -c na$sl/_nassl/nassl_SSL.c -o build/temp.linux-aarch64-3.7/nassl/_nassl/nassl_SSL.o -Wall
nassl/_nassl/nassl_SSL.c: In function ‘nassl_SSL_get_available_compression_methods’:
nassl/_nassl/nassl_SSL.c:322:53: error: dereferencing pointer to incomplete type ‘SSL_COMP {aka const struct ssl_comp_st}’
         methodPyString = PyUnicode_FromString(method->name);
                                                     ^~
nassl/_nassl/nassl_SSL.c: In function ‘get_tmp_new_cipher’:
nassl/_nassl/nassl_SSL.c:461:39: error: dereferencing pointer to incomplete type ‘SSL {aka struct ssl_st}’
     if (self->ssl == NULL || self->ssl->s3 == NULL)
                                       ^~

Can we replace sslyze with something better?

Solution:

It should take less effort to upgrade sslyze than to build ancient nassl for ARM.

Requirements / Acceptance Criteria:

What must a solution address in order to solve the problem? How do we know the solution is complete?

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?

aws / s2n-tls