Feat: ssl_supported_protocols (TLSv1.3) + ssl_cipher_suites

[kares]

The intent here is to officially support TLS 1.3 with an option to limit the protocol (both in server/client mode) with:

• ssl_supported_protocols => TLSv1.3

As well as being able to limit the TLS cipher suites used between client and server using:

• ssl_cipher_suites => [ ... ]

Unfortunately to be able to support the feature a recent version of JRuby-OpenSSL is required and since the gem version is locked in 7.x and 8.0 versions we need to play some clever tricks to disable the >= 0.12.2 requirement -> tests than feature detect the version available and adjust accordingly.

[yaauie]

This change is effectively breaking, preventing this minor-bumped feature from being installed on most Logstashes in the 7.x series where JOSSL is pinned, despite this PR otherwise doing a fair bit of work to ensure that the old functionality could run on those older Logstashes.

Can we continue to pin to >= 0.10.2, which will select JOSSL 0.12 on newer Logstashes and will allow installation on older Logstashes where the upgraded JOSSL is not available? If so, to prove that we can run the subset of behaviours we test for, can we include an old-JOSSL-pinned Logstash in the matrix (say: 7.17.2, which is pinned to ~> 0.11)

[kares]

This change is effectively breaking, preventing this minor-bumped feature from being installed on most Logstashes in the 7.x series where JOSSL is pinned,

The locking in LS was very unfortunate, esp. since it was a work-around for a build issue most of the time but took a while to actually look into, so the issue will be "breaking" on some 7.x versions (note that e.g. 6.8 did not do JOSSL locking) :

• LS 7.9.0 "jruby-openssl", "~> 0.10" ✔️

• LS 7.10.2 "jruby-openssl", "= 0.10.4" ❗

• LS 7.11.2 "jruby-openssl", "~> 0.10" ✔️

• LS 7.12.1 "jruby-openssl", "~> 0.10" ✔️

• LS 7.13.4 "jruby-openssl", "= 0.10.5" ❗

• LS 7.14.2 "jruby-openssl", "= 0.10.5" ❗

• LS 7.15.2 "jruby-openssl", "~> 0.11" ✔️

• LS 7.16.x "jruby-openssl", "~> 0.11" ✔️

• LS 7.17.0 "jruby-openssl", "~> 0.11" ✔️

• LS 7.17.1 "jruby-openssl", "= 0.11.0" ❗

• LS 7.17.2 "jruby-openssl", "~> 0.11.0" ❗

• LS 7.17.3 "jruby-openssl", "~> 0.11.0" ❗

• LS 7.17.4 "jruby-openssl", "~> 0.11" ✔️ (future release)

• LS 8.0.1 "jruby-openssl", "= 0.11.0" ❗

• LS 8.1.2 "jruby-openssl", "~> 0.11" ✔️

despite this PR otherwise doing a fair bit of work to ensure that the old functionality could run on those older Logstashes.

Right, we did some feature detection (although not that much) in tests but it's now been reverted 6c99df9 ... in order to not have the condition around the add_runtime_dependency (keeping the CI 🟢) - as suggested in #198 (comment)

Can we continue to pin to >= 0.10.2, which will select JOSSL 0.12 on newer Logstashes and will allow installation on older Logstashes where the upgraded JOSSL is not available? If so, to prove that we can run the subset of behaviours we test for, can we include an old-JOSSL-pinned Logstash in the matrix (say: 7.17.2, which is pinned to ~> 0.11)

Believe this has already been discussed: #198 (comment) ... we can not continue to use >= 0.10.2 as we need 2 features from 0.12.2 to provide the functionality in this PR. It's one thing that we do feature detection in tests (to work around pinned JOSSL) and another that we would need to document what features work depending on what version of logstash is used ...

[kares]

@yaauie the plugin is updated to require LS >= 8.1 (which already has jruby-openssl 0.12.2)
this means we no longer need special checks for Java 8 (due TLSv1.3 support) thus all of the code has been removed.

[jsvd]

as mentioned in the tcp output review, we can enable the exact list of supported protocols in the context instead of max/min, so that the behaviour is more consistent with the java context.

[jsvd]

LGTM

[AnandhkumarG]

Hi , Does this feature require Logstash 8.1.x as minimum? WIll this feature work in 7.17.x for example. Please let know if there is a compatiibility matrix for plugins versions-LS versions. Thanks in advance