@kares

Thanks for the PR. Not sure about JRuby's OpenSSL implementation, but with MRI OpenSSL, there are two cipher functions, one to set ciphers for TLSv1.2 and below (SSL_CTX_set_cipher_list), and one specific to TLSv1.3 (SSL_CTX_set_ciphersuites).

Re TLSv1.3, are there systems that are only allowing it as a protocol? I assumed that TLSv1.2 would be considered an 'allowed' protocol for at least a few years. Maybe an incorrect assumption...

Thanks Greg for the review 💜

Not sure about JRuby's OpenSSL implementation, but with MRI OpenSSL, there are two cipher functions, one to set ciphers for TLSv1.2 and below (SSL_CTX_set_cipher_list), and one specific to TLSv1.3 (SSL_CTX_set_ciphersuites).

as noted in the description Puma is already using Java specific concepts to setup MiniSSL on JRuby (keystore, truststore) simply because that is what we have in JDK - using PEM files would need additional work. in that regard I was about to add protocols so I thought about having ssl_cipher_list option aligned with the Java naming.

the 2 functions in OpenSSL are a bit unfortunate esp. the fact that there are 2 also leaked into Ruby OpenSSL APIs. with Java there's one way to set ciphers for both 1.2 and 1.3 - the API has been named setEnabledCipherSuites even before TLSv1.3 existed.

Re TLSv1.3, are there systems that are only allowing it as a protocol? I assumed that TLSv1.2 would be considered an 'allowed' protocol for at least a few years. Maybe an incorrect assumption...

the protocols option is about giving users a choice to configure which TLS versions their server supports, there's a way to do that with OpenSSL as well just the exposed API is less explicit (min_version, max_version, what specific version NOT to enable).

@kares

To control protocol selection Puma only has no_tlsv1 and no_tlsv1_1

Long story. no_tlsv1 was added 11-May-2018. Re OpenSSL 1.0.2, the last release was 1.0.2u, on 20-Dec-2019, and it's been out of public support since at least 21-April-2020.

So, I think it's time to add something like tls_min_version and tls_max_version, which will only work with OpenSSL 1.1.1 or later. I've got much of the code done on the MRI side, then realized it would have merge conflicts here.

So, any thoughts re adding that, and might it be an option to using protocols for JRuby?

Note that I'm using the same strings to reference TLS versions as the code here, and it would be easy to assemble a string (or array) like TLSv1.2,TLSv1.3 from the code I have. IOW, use tls_min_version and tls_max_version in the bind string and the DSL code, but use them to set ctx.protocols when using JRuby? I.think.that.made.sense...

So, any thoughts re adding that, and might it be an option to using protocols for JRuby?

I'm fine with protocols as well as having tls_min_version and tls_max_version.
we're exposing the Java engine specifics already e.g. we do not have the same enabled ciphers setting and even those settings use different cipher naming. thus I went with being "aligned" and added protocols. having min/max version setting would be fine as well -> if that is something you guys would prefer to start with it's a start.

One (very edgy) downside of the tls_min_version and tls_max_version approach is that selecting non intervals gets verbose/impossible e.g. you want 1.1 and 1.3 one would need to set OP_NO_TLSv1_2
while with protocols = [ 'TLSv1.1', 'TLSv1.3' ] it's simple.