Added 'ciphersuites=' method to allow setting of TLSv1.3 cipher suites along with some unit tests

[kmdz1]

Added an instance method, 'ciphersuites=', to OpenSSL::SSL::SSLContext which allows users to set the TLSv1.3 cipher suites. Also, added unit tests for this method and improved the test coverage for the existing 'ciphers=' method.

Resolves #476

[ioquatix]

How is this different to just straight ciphers?

[eviljoel]

I work with twkmd12 and can vouch that we need this change.

To answer @ioquatix's question, TLSv1.3 almost completely ignores the 'ciphers' property. (If I remember right, I think the only thing you can do via the 'ciphers' property that affects TLSv1.3 is to disable all TLSv1.3 ciphers [along with all other ciphers for all other SSL/TLS versions].) The only way to get fine grained control of the ciphers used by TLSv1.3 is via the ciphersuites property.

One reason we want this feature is to get access to the CCM TLSv1.3 ciphers which are disabled by default.

Please let me know if you need more details.

[kmdz1]

How is this different to just straight ciphers?

'ciphers=' sets cipher suites for TLSv1.2 and below, while 'ciphersuites=' sets them for TLSv1.3.

[ioquatix]

I understand the need for this functionality but I'm just wondering:

1. Whether we can't just reuse ciphers= for it (sounds like no?). If semantically it's different it makes sense different accessors, I'm just concerned it introduces more complexity for users.
2. Whether we need to communicate clearly the use cases where one would use ciphers and ciphersuites. It sounds like we would eventually (i.e. in 5-10 years) deprecate ciphers.

[kmdz1]

@ioquatix The behavior of the two OpenSSL functions does differ, so the setters should be separated. For example, the 'str' argument provided to SSL_CTX_set_cipher_list, which only sets TLSv1.2 and below cipher suites, is much more complex (e.g. there's support for logical operators) and there are many more cipher suites involved. Whereas with SSL_CTX_set_ciphersuites, which only sets TLSv1.3 cipher suites, there are at most five cipher suites; usually three, because the two CCM AEAD mode cipher suites are often disabled and the 'str' argument is a colon delimited list of these cipher suites in order of preference. Also, it looks like TLSv1.3 cipher suites are given a higher preference than others, so using one setter would break preference ordering.

Note: OpenSSL's s_client and s_server utilities have different command line options for setting TLSv1.2 and below cipher suites, and TLSv1.3 cipher suites (-ciphers and -ciphersuites respectively).

Seems to me like your option 2 is the best course. It looks like there's a push away from the prior complexity and eventually 'ciphers=' will need to be deprecated.

[ioquatix]

Thanks for explaining this. I understand now exactly what is being proposed.

[ioquatix]

LGTM.

[rhenium]

Thank you for working on this!

I left some change requests within the test code. The implementation itself looks good!

[kmdz1]

@rhenium Thank you for the suggestions!

[kmdz1]

Will get to the bottom of why the Windows tests are failing.

[ioquatix]

Just ping me again here if you need to run more tests :)

[kmdz1]

@ioquatix @rhenium Can we get this merged?

[rhenium]

All GitHub Actions checks pass now and everything looks ready for merge. Thanks for your work!