[
https://issues.apache.org/jira/browse/IGNITE-29252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov resolved IGNITE-29252.
---------------------------------------
Resolution: Fixed
[~xianreallyhotzzh], thanks for your contribution!
> JdbcThinConnectionSSLTest picks a cipher suite that the client or the server
> cannot use
> ---------------------------------------------------------------------------------------
>
> Key: IGNITE-29252
> URL: https://issues.apache.org/jira/browse/IGNITE-29252
> Project: Ignite
> Issue Type: Bug
> Environment: Amazon Corretto 17.0.15, macOS; Apache master
> 39d2c0112fd7fec0a5407f41b2eba52f5f012afa.
> Reporter: Anton Vinogradov
> Assignee: Zhang Zhenhao
> Priority: Minor
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> {{testUnsupportedCustomCipher}} and {{testDisabledCustomCipher}} in
> {{JdbcThinConnectionSSLTest}} can pick a cipher suite that the JDBC client or
> the server cannot use. Then the tests fail for a reason that has nothing to
> do with the JDBC client.
> h3. Problem
> Both tests need a cipher suite that the JDK supports but does not enable by
> default. The test helper takes such suites from a {{TLSv1.2}} context,
> removes anonymous suites and takes the first one from a {{HashSet}}. The
> picked suite can be wrong in three ways:
> * The JDBC client uses the {{TLS}} protocol, and {{TLS}} enables TLS 1.3
> suites by default. On Corretto 17.0.15 the helper picks
> {{TLS_AES_128_GCM_SHA256}}. The client then connects with its default suites,
> and {{testUnsupportedCustomCipher}} fails with "Exception has not been
> thrown."
> * With {{-Djdk.tls.client.protocols=TLSv1.2}} the client cannot use TLS 1.3.
> The helper still picks a TLS 1.3 suite, and both tests fail with "Failed to
> SSL connect to server".
> * The server key in {{server.jks}} is RSA. When the JDK allows NULL suites,
> the candidates include {{TLS_ECDHE_ECDSA_WITH_NULL_SHA}}, and its handshake
> with an RSA key fails. TeamCity allows NULL suites and picks
> {{TLS_ECDHE_RSA_WITH_NULL_SHA}}, so the tests pass there only because of the
> set order.
> When the JDK has no suitable suite, the helper fails the test. The DES check
> in {{testDisabledCustomCipher}} does not need such a suite, but it does not
> run either.
> h3. Reproduce
> Use Amazon Corretto 17.0.15 and master
> {{39d2c0112fd7fec0a5407f41b2eba52f5f012afa}}:
> {code:bash}
> mvn -pl modules/clients -am test
> -Dtest=JdbcThinConnectionSSLTest#testUnsupportedCustomCipher
> -Dsurefire.failIfNoSpecifiedTests=false -DFORK_COUNT_SET_TO_1
> {code}
> One test runs and fails; there are no errors or skips.
> h3. Expected result
> * The helper picks only a suite that is not among the client's default suites
> and that the client can negotiate with the server's RSA key under the
> client's enabled protocols. Any other suite makes the tests fail even when
> the JDBC client works correctly.
> * If the JDK has no such suite, both tests skip the steps that need it and
> say why in the skip message.
> * The DES check in {{testDisabledCustomCipher}} runs on every JDK. Without
> that, a JDK with no suitable suite also loses this unrelated check.
> No production TLS behavior change is needed.
> h3. How to verify
> Run the whole {{JdbcThinConnectionSSLTest}} class on Corretto 17 in four
> setups:
> * the stock JDK;
> * the stock JDK with {{-Djdk.tls.client.protocols=TLSv1.2}};
> * NULL suites allowed: {{-Djava.security.properties}} with a file that
> removes {{NULL}} from {{jdk.tls.disabledAlgorithms}};
> * both of the above.
> The class has no failures in any setup. The two custom-cipher tests run their
> cipher steps where NULL suites are allowed and skip them elsewhere.
> Related: IGNITE-29051 introduced the helper and is resolved. The failure also
> reproduces outside the TLS reload series; it is tracked separately from
> IGNITE-29209.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
