[Meta] Support TLS 1.3

[jsvd]

TLS v1.3 is available since Java 8u262-b10 (AdoptOpenJDK) or 8u261-b12 in the Oracle build.
https://java.com/en/jre-jdk-cryptoroadmap.html

Logstash 7.15/16 ships with Java 11 and 8.0 will even drop support for Java 8 -> TLS v1.3 could be assumed available.

This issue intends to track all the work towards being confident that Logstash supports TLS v1.3.

---

Core

• Puma providing 1.3 support under JRuby: http server requirements due secure api #13406
• [Meta] Add TLSv1.3 support to the Logstash API endpoint  #15153
• using the vendor-ed JDK LS should default to enabling TLSv1.2 and TLSv1.3 in the Java SSL engine

---

Dependencies

• confirm Manticore (Apache HttpClient 4.x) works as expected against TLSv1.3
• JRuby-OpenSSL lacks support for TLSv1.3 (initial support available in 0.12.1)
  scope unknown -> need to review Ruby OpenSSL + C-OpenSSL changes
• extra JOSSL support to be able to select Java cipher names for an SSL context
  to allow easy cipher_suites => ... support for low level plugins such as the tcp input (requested feature)
• Puma does not support TLSv1.3 using it's MiniSSL JRuby implementation
  scope should be relatively simple

---

Plugins

• ES output - Feat: add ssl_supported_protocols option logstash-plugins/logstash-output-elasticsearch#1055 - should work out-of-the box against ES when secured or even restricted to 1.3 only

  • integration tests against ES using xpack.security.http.ssl.supported_protocols: TLSv1.3
  • (optional) support for ssl_supported_protocols option (default => ['TLSv1.2', 'TLSv1.3'])
    would be nice if the naming prefix would align with planned TLS configuration unification

• ES input - Test: against ES with configured TLSv1.3 logstash-plugins/logstash-input-elasticsearch#162 - should work out-of-the box against ES when secured or even restricted to 1.3 only

  • integration tests against ES using xpack.security.http.ssl.supported_protocols: TLSv1.3
    should be working -> testing relies on using the Elasticsearch transport Ruby http adapter (need TLSv1.3 in JOpenSSL)
  • (optional) enabled protocol version configuration does not make much sense given only ca_file TLS configuration is supported atm

• ES filter - should work out-of-the box against ES when secured or even restricted to 1.3 only
  Test: against ES with configured TLSv1.3 logstash-plugins/logstash-filter-elasticsearch#154

  • integration tests against ES using xpack.security.http.ssl.supported_protocols: TLSv1.3
  • (optional) enabled protocol version configuration does not make much sense given only ca_file TLS setting

• HTTP mixin Feat: add ssl_supported_protocols option logstash-plugins/logstash-mixin-http_client#40

• HTTP output Feat: added ssl_supported_protocols option logstash-plugins/logstash-output-http#131

  • (optional) enabled protocol version configuration

• HTTP Poller input - Manticore based (HTTP mixin)
  Feat: added ssl_supported_protocols option logstash-plugins/logstash-input-http_poller#133

  • (optional) enabled protocol version configuration

• HTTP filter - Manticore based (HTTP mixin)
  Feat: added ssl_supported_protocols option logstash-plugins/logstash-filter-http#38

  • (optional) enabled protocol version configuration

• TCP input - Netty based for server mode, JOpenSSL in client mode (blocked by JRuby-OpenSSL 1.3 support)
  Feat: ssl_supported_protocols (TLSv1.3) + ssl_cipher_suites logstash-plugins/logstash-input-tcp#198

  • need a new configuration option e.g. ssl_supported_protocols
  • plugin is lacking TLS tests
  • support for configuring TLS ssl_cipher_suites

• HTTP input Feat: TLSv1.3 support logstash-plugins/logstash-input-http#146

  • expose TLSv1.3 in min/max version configuration (consider deprecating the min/max options)
  • new configuration option (ssl_supported_protocols) in favor of tls_min_version / tls_max_version
    Feat: review and deprecate ssl protocol/cipher settings logstash-plugins/logstash-input-http#151
  • plugin is lacking TLS tests (testing depends on Manticore)

• TCP output - using JOpenSSL (blocked by JRuby-OpenSSL TLS 1.3 support)
  Feat: ssl_supported_protocols (TLSv1.3) logstash-plugins/logstash-output-tcp#47

  • need a new configuration option
  • TLSv1.3 testing
  • (extra) support for configuring TLS cipher_suites (similar to Beats input)

• Beats input - Netty based - does only enable TLS 1.2 review plugin for TLS 1.3
  Feat: add support for TLSv1.3 logstash-plugins/logstash-input-beats#447

  • need a new configuration option ssl_supported_protocols (Beats naming ssl.supported_protocols)
    Feat: review and deprecate ssl protocol/cipher settings logstash-plugins/logstash-input-beats#450
  • cipher_suites setting should account for TLS 1.3 suite names
  • consider abandoning the cipher_suites default on recent LS (Java >= 11) to rely on Java defaults
  • TLS 1.3 (integration) testing

[karenzone]

Related: #12024

[endorama]

Hello, looking at the status of this issue it seems TLS 1.3 is still not supported by Logstash, but I found an old PR (June 2020) where TLS 1.3 is mentioned.

Could you please confirm if it's supported or not? I come here from the Beats input documentation page that says max TLS version supported is 1.2, but I'm not sure is correct.

Thanks!

[tsaarni]

I can help with beats input.

[kares]

@endorama the story is in general that TLS 1.3 support depends plugin by plugin and also the JDK used (in case of old LS versions or running on older Java 8 versions).

for Beats, unfortunately, the tls_max_version parameter is hard-coded to 1.2 thus it does not adapt to enabling 1.3 despite the underlying Java SSL engine having the support (likely relates to the cipher_suites parameter which also needs revisiting). part of this meta issue we plan to look into getting Beats ready for TLS 1.3 - work is done plugin by plugin, hopefully Beats will be completed within the next few weeks.

@tsaarni thanks for the effort, whatever progress you're able to do I can built upon, what might server as an example to some extent is what we did in TCP input ... as to how much existing Beats option we'll deprecate in favor of a naming similar to the TCP input added options is undecided at this point.