Bring sslscan into a OpenSSL 3.x world

[tetlowgm]

This set of code changes drags sslscan kicking and screaming into the modern era with OpenSSL. There isn't any functional code changes, it's mostly purging old ifdef's and dropping old code that has runtime detection for ancient versions of OpenSSL.

This also moves over several calls that have drop-in modern methods.

Still outstanding deprecated feature usage will require deeper code changes to deal with. Specifically protocol versioned SSL_METHOD (which is sprinkled absolutely everywhere in the codebase) and moving away from key type specific object (EC_KEY, DH, RSA, etc) to the generic EVP_PKEY framework.

[jtesta]

I attempted to compile the changes introduced in this PR, but failed:

sslscan.c: In function ‘testHost’:
sslscan.c:3487:17: error: expected expression before ‘[’ token
 3487 |                 [[fallthrough]];
      |                 ^
sslscan.c:3487:19: error: ‘fallthrough’ undeclared (first use in this function)
 3487 |                 [[fallthrough]];
      |                   ^~~~~~~~~~~

Once this is fixed, bonus points if you can run ./docker_test.sh without any failures!

[tetlowgm]

Sorry, that was a c23-ism that snuck in. I've fixed the commit for that.

I don't have a docker setup; I'm a FreeBSD/MacOS guy myself. Can I trouble you to run the docker test for me? I will see what it would take to get a functional setup, but that's going to be a bit.

[jtesta]

Yep, the docker tests all pass. Nice!

[rbsec]

Thanks for submitting this (and @jtesta for testing).

The main hesitation that I have with requiring OpenSSL 3.x is that it's only been out for three years, which means that there are still several widely used and supported distros (such as Ubuntu 20.04 LTS and RHEL 8, although that Ubuntu release seems to have dropped the package) that are shipping OpenSSL 1.x with backported security patches - so requiring 3.x means breaking their builds, as they generally don't seem keen on statically compiling packages.

But the distro packaged versions of sslscan are often pretty outdated and built against versions of OpenSSL that don't support everything we'd want them to - and with the ease of both static builds and Docker builds I'm not sure that's a significant issue. And most of the people using sslscan won't be doing so from those older distros.

So I guess the question would be whether we gain much from dropping support for OpenSSL 1.x? If it's the first step of a wider cleanup and refactoring process, or that legacy support is causing issues elsewhere then that makes perfect sense - but I'm always a little hesitant to drop backwards compatibility without a good reason.

@jtesta what're your thoughts?