[
https://issues.apache.org/jira/browse/HBASE-26666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17579645#comment-17579645
]
Andor Molnar commented on HBASE-26666:
--------------------------------------
Thanks for the help [~bbeaudreault] [~zhangduo] . I was distracted in the past
few days and couldn't focus on what's happening.
I agree with the outstanding items, will work on them in the order of your
list.
A quick 2.6.0 release sounds good to me, though since 2.5 is still not
released, I expected the TLS feature to fit in. You don't think it's feasible
at this point in time?
> 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)
