[
https://issues.apache.org/jira/browse/HBASE-28122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Charles Connell updated HBASE-28122:
------------------------------------
Description:
The X509Util class has a system for choosing the cipher suites to support on
TLS connections, if {{hbase.rpc.tls.ciphersuites}} is not provided. It also
allows you choose what protocol you want via the
{{hbase.rpc.tls.enabledProtocols}} config. If
{{hbase.rpc.tls.enabledProtocols}} is set to {{{}TLSv1.3{}}}, and
{{hbase.rpc.tls.ciphersuites}} is not set, the user of X509Util cannot form any
working TLS connections.
This is because all the cipher suites chosen by X509Utils are pre-TLSv1.3
suites, and so are rejected during connection handshakes. TLSv1.3 requires or
suggests support for these suites, none of which are shared in common with
TLSv1.2:
* TLS_AES_256_GCM_SHA384
* TLS_CHACHA20_POLY1305_SHA256
* TLS_AES_128_GCM_SHA256
Of these, BoringSSL and Java 11+ support {{TLS_AES_128_GCM_SHA256}} and
{{{}TLS_AES_256_GCM_SHA384{}}}, so those should be added to the defaults in
X509Util. BoringSSL and the JVM are the two crypto providers used here.
was:
The X509Util class has a system for choosing the cipher suites to support on
TLS connections, if {{hbase.rpc.tls.ciphersuites}} is not provided. It also
allows you choose what protocol you want via the
{{hbase.rpc.tls.enabledProtocols}} config. If
{{hbase.rpc.tls.enabledProtocols}} is set to {{{}TLSv1.3{}}}, and
{{hbase.rpc.tls.ciphersuites}} is not set, the user of X509Util cannot form any
working TLS connections.
This is because all the cipher suites chosen by X509Utils are pre-TLSv1.3
suites, and so are rejected during connection handshakes. TLSv1.3 suggests
support for these suites, none of which are shared in common with TLSv1.2:
* TLS_AES_256_GCM_SHA384
* TLS_CHACHA20_POLY1305_SHA256
* TLS_AES_128_GCM_SHA256
Of these, BoringSSL and Java 11+ support {{TLS_AES_128_GCM_SHA256}} and
{{{}TLS_AES_256_GCM_SHA384{}}}, so those should be added to the defaults in
X509Util. BoringSSL and the JVM are the two crypto providers used here.
> TLSv1.3-compatible cipher suites are not used by default
> --------------------------------------------------------
>
> Key: HBASE-28122
> URL: https://issues.apache.org/jira/browse/HBASE-28122
> Project: HBase
> Issue Type: Bug
> Affects Versions: 2.5.5
> Reporter: Charles Connell
> Assignee: Charles Connell
> Priority: Major
>
> The X509Util class has a system for choosing the cipher suites to support on
> TLS connections, if {{hbase.rpc.tls.ciphersuites}} is not provided. It also
> allows you choose what protocol you want via the
> {{hbase.rpc.tls.enabledProtocols}} config. If
> {{hbase.rpc.tls.enabledProtocols}} is set to {{{}TLSv1.3{}}}, and
> {{hbase.rpc.tls.ciphersuites}} is not set, the user of X509Util cannot form
> any working TLS connections.
> This is because all the cipher suites chosen by X509Utils are pre-TLSv1.3
> suites, and so are rejected during connection handshakes. TLSv1.3 requires or
> suggests support for these suites, none of which are shared in common with
> TLSv1.2:
> * TLS_AES_256_GCM_SHA384
> * TLS_CHACHA20_POLY1305_SHA256
> * TLS_AES_128_GCM_SHA256
> Of these, BoringSSL and Java 11+ support {{TLS_AES_128_GCM_SHA256}} and
> {{{}TLS_AES_256_GCM_SHA384{}}}, so those should be added to the defaults in
> X509Util. BoringSSL and the JVM are the two crypto providers used here.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
