added stronger TLS ciphers default

[ThyTran1402]

Description

The default TLS configuration allowed weak protocols (TLSv1.1) and cipher suites (CBC-mode, SHA-1 MAC, DHE_DSS, IBM SSL_-prefix) that are considered insecure by modern standards.

• Old behavior:
  Default protocols: ["TLSv1.3", "TLSv1.2", "TLSv1.1"]
  Default ciphers: 37 entries including CBC-mode, SHA-1 MAC, DHE_DSS, and IBM SSL_-prefix duplicates, based on Chrome 48 / Firefox 42 support
  Outbound connectors defaulted to ["TLSv1.2", "TLSv1.1"]
  Explicitly configuring TLSv1/TLSv1.1 logged a deprecation warning
• New behavior
  Default protocols: ["TLSv1.3", "TLSv1.2"] (Mozilla Intermediate TLS profile)
  Default ciphers: 10 entries — TLS 1.3 suites + ECDHE+GCM + ECDHE+ChaCha20 for TLS 1.2 only
  All outbound connectors share the same default protocol list via a new SSLConfigConstants.DEFAULT_SSL_PROTOCOLS constant
  Explicitly configuring TLSv1 or TLSv1.1 now causes a hard startup failure

Issues Resolved

#2157

Testing

• Updated SSLConfigConstantsTest: default protocol assertions updated to reflect removal of TLSv1.1
• SslParametersTest required no changes: existing assertions already expect ["TLSv1.3", "TLSv1.2"] since the JDK intersection step drops TLSv1.1 on modern JVMs
• Manual verification: node fails to start when enabled_protocols explicitly includes TLSv1.1, confirming the hard startup error path

Check List

• New functionality includes testing
• New functionality has been documented
• New Roles/Permissions have a corresponding security dashboards plugin PR
• API changes companion pull request created
• Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[cwperks]

@ThyTran1402 I agree with the direction, but changing setting defaults is something that would be done on major releases. We don't currently have a branch tracking the next major release, but I'll see if I can bring up where to stage changes for a major release.

[ThyTran1402]

@ThyTran1402 I agree with the direction, but changing setting defaults is something that would be done on major releases. We don't currently have a branch tracking the next major release, but I'll see if I can bring up where to stage changes for a major release.

That really makes sense to me. Since changing defaults will break change in existing deployments that rely on the current defaults would break after upgrading.

So, should I keep this branch open for the next major release, or would you like I open a tracking issue instead, so the work isn't lost? @cwperks