You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Bryan Beaudreault (Jira)" <ji...@apache.org> on 2022/08/23 13:33:00 UTC

[jira] [Updated] (HBASE-27318) Configuration to allow client fallback to non-SSL if handshake fails

     [ https://issues.apache.org/jira/browse/HBASE-27318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bryan Beaudreault updated HBASE-27318:
--------------------------------------
    Summary: Configuration to allow client fallback to non-SSL if handshake fails  (was: Configuration to allow fallback to non-SSL if handshake fails)

> Configuration to allow client fallback to non-SSL if handshake fails
> --------------------------------------------------------------------
>
>                 Key: HBASE-27318
>                 URL: https://issues.apache.org/jira/browse/HBASE-27318
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: Bryan Beaudreault
>            Priority: Major
>
> [~zhangduo] brought up a great idea when reviewing the new native TLS docs. Since HMasters and RegionServers are both clients and servers, currently it requires multiple cluster restarts to transition an existing cluster to TLS:
> {quote}1. Enable {{hbase.server.netty.tls.enabled}} only, with supportPlaintext=true. After restart, servers will _accept_ TLS, but not _send_ TLS. 
> 2. Additionally enable {{hbase.client.netty.tls.enabled}} on servers, keeping supportPlaintext=true. After restart, servers will now _accept and send_ TLS.
> 3. Remove supportPlaintext=true. After restart, servers will reject requests if not TLS.
> Clients can be updated to use {{hbase.client.netty.tls.enabled}} either after step 1 or 2, but before 3.
> {quote}
> This could be simplified by allowing the client-side to also fallback to plaintext if handshake fails:
> {quote}Theoretically at client side it is possible. In the NettyRpcConnection implementation, before the ssl handshake finishes, we will not send any data out. So if we want to fallback to non ssl communication, we could just remove the ssl handler and set up the connection without encryption. But probably at server side we will just close the connection...
> {quote}
> We'd need to test to see how the server-side handles this downgrade, per the last sentence above.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)