[
https://issues.apache.org/jira/browse/RATIS-2596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18095596#comment-18095596
]
Haonan Hou commented on RATIS-2596:
-----------------------------------
As a follow-up, another possible solution would be to make the cipher-suite
filtering strategy configurable in TlsConf, instead of selecting the behavior
automatically based on the JSSE provider.
For example:
public enum CipherSuiteFilterMode {
SUPPORTED_ONLY,
PASSTHROUGH
}
SUPPORTED_ONLY could remain the default, preserving the protection introduced
by RATIS-2596. Applications that use provider-specific cipher suites could
explicitly select PASSTHROUGH:
TlsConf.newBuilder()
.setCipherSuiteFilterMode(CipherSuiteFilterMode.PASSTHROUGH)
.setCipherSuites(cipherSuites)
.build();
Ratis could then select the filter as follows:
CipherSuiteFilter filter =
tlsConf.getCipherSuiteFilterMode() == CipherSuiteFilterMode.PASSTHROUGH
? IdentityCipherSuiteFilter.INSTANCE
: SupportedCipherSuiteFilter.INSTANCE;
builder.ciphers(cipherSuites, filter);
This option would be independent of the selected SSL provider and could be
applied consistently to both the JDK/JSSE and OpenSSL paths, as well as the
gRPC and Netty DataStream transports.
PASSTHROUGH would only disable Netty's supported-set filtering. It would not
add cipher-suite support to the underlying TLS implementation. Validation
would instead be delegated to SSLEngine or netty-tcnative/OpenSSL. Therefore,
a truly unsupported or misspelled cipher suite could still cause SslContext
construction, SSLEngine initialization, or the TLS handshake to fail.
This approach keeps the safer filtering behavior as the default, while giving
applications an explicit escape hatch when the provider accepts a cipher suite
that is missing from the supported set observed by Netty.
> Unsupported TLS cipher suites may crash gRPC servers
> ----------------------------------------------------
>
> Key: RATIS-2596
> URL: https://issues.apache.org/jira/browse/RATIS-2596
> Project: Ratis
> Issue Type: Improvement
> Components: gRPC
> Affects Versions: 3.3.0
> Reporter: István Fajth
> Assignee: István Fajth
> Priority: Major
> Fix For: 3.3.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In HDDS-15176 we realized that letting the SSL ciphers to be configured for
> gRPC with Netty can lead to misconfiguration where a cipher that is not
> supported by Netty is configured, and that crashed the gRPC endpoint in Ozone.
> In order to avoid similar situations in Ratis, I propose to change from the
> IdentityCipherSuiteFilter to the SupportedCipherSuiteFilter in the gRPC TLS
> setup in GrpcUtil#configureSslContextBuilder.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
