XianReallyHot-ZZH opened a new pull request, #13801:
URL: https://github.com/apache/ignite/pull/13801
### Root cause
`disabledByDefaultCipherSuites()` subtracts the **default cipher suites of a
`TLSv1.2` context** from the supported suites to find a suite that is
"supported by the JDK, but not enabled by default". That default set does not
contain the TLS 1.3 suites (`TLSv1.2` cannot use them), so on JDKs whose
security properties trim the weak TLS 1.2 suites out of the supported list,
the only remaining candidates are the three TLS 1.3 suites.
The JDBC thin client however builds its context with the default protocol
`"TLS"` (`JdbcThinSSLUtil` falls back to
`SslContextFactory.DFLT_SSL_PROTOCOL`
when no `sslProtocol` connection property is set), and a `"TLS"` context
enables the TLS 1.3 suites by default. So the suite picked by the helper is
among the client's default ciphers, the "Default ciphers" check of
`testUnsupportedCustomCipher` negotiates it successfully, and the expected
`SQLException` is never thrown ("Exception has not been thrown").
Verified on Microsoft OpenJDK 17.0.21 (macOS, x64):
`SSLContext.getInstance("TLSv1.2")`
supported-minus-defaults is exactly the 3 TLS 1.3 suites, while the client's
`"TLS"` context enables all three by default; on unpatched master the test
fails at the "Default ciphers" assertion (same line/message as the ticket).
The failure is masked on TC because CI sets
`-Djdk.tls.client.protocols=TLSv1.2`,
which forbids the client from negotiating TLS 1.3 at all.
### Fix
* The helper subtracts the defaults of the client's default protocol
(`SslContextFactory.DFLT_SSL_PROTOCOL`) — the same protocol the client uses
when no explicit cipher suites are set — so the selected suite is never
among the client's default ciphers on any runtime.
* On providers where every supported suite is enabled by default (e.g. stock
OpenJDK 17: supported == default == 31 suites) the scenario cannot be
constructed; the helper now `Assume.assumeTrue`-skips the two tests with an
explanatory message instead of failing.
* Drive-by: "Fulter" -> "Filter" comment typo in the same method.
No production code is touched.
### Testing
* `testUnsupportedCustomCipher` on unpatched master (no
`jdk.tls.client.protocols`): **fails — exact ticket symptom reproduced**.
* After the fix, in a TC-like environment (java.security override restoring
the weak suites to the supported list, as on TC where
`testCustomCiphersOnClient` negotiates a NULL suite explicitly):
* `testUnsupportedCustomCipher` + `testDisabledCustomCipher`: **2/2 green,
0 skipped**
* full `JdbcThinConnectionSSLTest` class: **16/16 green, 0 skipped**
* After the fix, stock OpenJDK 17.0.21: full class **0 failures**; the two
custom-cipher tests skip by design (no candidate suite exists on this
runtime); the 2 errors in `testCustomCiphersOnClient`/`OnServer` are
pre-existing (they hardcode suites absent from this JDK's supported list —
identical errors occur on unpatched master).
* After the fix, with the CI's `-Djdk.tls.client.protocols=TLSv1.2`: error
set identical to the unpatched baseline on the same JDK — zero regressions.
* `checkstyle:check` on modules/clients: green.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
