You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Charles Connell (Jira)" <ji...@apache.org> on 2023/09/29 18:55:00 UTC
[jira] [Updated] (HBASE-28122) TLSv1.3-compatible cipher suites are not used by default
[ 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)