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

[jira] [Commented] (HBASE-26666) Add native TLS encryption support to RPC server/client

    [ https://issues.apache.org/jira/browse/HBASE-26666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17576376#comment-17576376 ] 

Duo Zhang commented on HBASE-26666:
-----------------------------------

I've filed HBASE-27278 and HBASE-27279 for test improvements and also sasl wrap fix.

There are still several things to do:

1. Documentation. This is tracked by HBASE-27226.
2. Fail fast when BlockingRpcClient or SimpleRpcServer is used when TLS is enabled. Need to open an issue.
3. Verify the behavior when trust store loaction is not specified. If there is no big problem then we just need to mention it in the documentation, otherwise we need an extra issue.
4. Let me just quote [~andor]'s words "How to store keystore/truststore password securely?". Maybe we should open a discussion thread on the dev list first?

Feel free to add more if I missed something.

Thanks.

> Add native TLS encryption support to RPC server/client
> ------------------------------------------------------
>
>                 Key: HBASE-26666
>                 URL: https://issues.apache.org/jira/browse/HBASE-26666
>             Project: HBase
>          Issue Type: New Feature
>          Components: encryption, security
>    Affects Versions: 3.0.0-alpha-2, 2.6.0, 2.4.12, 2.5.1
>            Reporter: Josh Elser
>            Assignee: Andor Molnar
>            Priority: Major
>              Labels: SSL, TLS, encryption, security
>             Fix For: 2.6.0, 3.0.0-alpha-4
>
>
> Today, HBase must complete the SASL handshake (saslClient.complete()) prior to turning on any RPC encryption (hbase.rpc.protection=privacy, sasl.QOP=auth-conf).
> This is a problem because we have to transmit the bearer token to the server before we can complete the sasl handshake. This would mean that we would insecurely transmit the bearer token (which is equivalent to any other password) which is a bad smell.
> Ideally, if we can solve this problem for the oauth bearer mechanism, we could also apply it to our delegation token interface for digest-md5 (which, I believe, suffers the same problem).
> The plan is to port Server/Client TLS implementation from the ZooKeeper project. It's a Netty based solution which looks like the best fit for NettyRpc client/server. 



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