[
https://issues.apache.org/jira/browse/IGNITE-29252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-29252:
--------------------------------------
Description:
{{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.
was:
On Corretto 17.0.15, {{testUnsupportedCustomCipher}} fails at the “Default
ciphers” assertion with “Exception has not been thrown.” on clean Apache master
{{39d2c011}}. The connection succeeds because the selected cipher is enabled by
the JDBC client’s default TLS context.
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. Cause and expected result
The test helper removes the defaults of a {{TLSv1.2}} context from its
supported suites. Its remaining candidates are {{TLS_AES_128_GCM_SHA256}},
{{TLS_AES_256_GCM_SHA384}} and {{TLS_CHACHA20_POLY1305_SHA256}}. The JDBC
client defaults to {{TLS}}, which enables all three on this runtime. The helper
selected {{TLS_AES_128_GCM_SHA256}} in the reproduction.
Choose the negative test’s cipher using the same protocol as its client, and
handle the case where the provider has no supported cipher disabled by default.
Verify both custom-cipher tests and the complete {{JdbcThinConnectionSSLTest}}
class. No production TLS behavior change is needed for this test correction.
Related: IGNITE-29051 introduced the helper change and is already resolved. The
failure also reproduces outside the TLS reload series; it is tracked separately
from IGNITE-29209.
Summary: JdbcThinConnectionSSLTest picks a cipher suite that the client
or the server cannot use (was: JdbcThinConnectionSSLTest selects a default TLS
cipher as disabled on Corretto 17)
> 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: 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)
