[
https://issues.apache.org/jira/browse/HBASE-26548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17456829#comment-17456829
]
Wellington Chevreuil commented on HBASE-26548:
--
[~bbeaudreault] , I had just attached the patch we mentioned over slack thread.
This was originally created from some point of branch-2.2, but I don't think it
will apply cleanly to any current head of branches.
As already mentioned over slack, this had modified netty rpc related
client/server classes to implement one way TLS in the rpc connections. It's not
pluggable, so if this applied, one way TLS will be always on.
I mentioned in the slack channel that it was using the test-only purpose
*InsecureTrustManagerFactory* to build an SSL context, but whilst reviewing
this patch today, I realised this is actually using the default JDK truststore.
When testing it, I had used server self signed cert, so needed to import the
server certificate into jdk default truststore, so that client can validate the
server certificate. Since this is one-way, client certificate is not required.
Let me know how it goes, I may be able to give you more details if you have
further questions.
> Investigate mTLS in RPC layer
> -
>
> Key: HBASE-26548
> URL: https://issues.apache.org/jira/browse/HBASE-26548
> Project: HBase
> Issue Type: New Feature
>Reporter: Bryan Beaudreault
>Priority: Major
> Attachments: 0001-One-way-TLS-on-Netty-RPC-Implementation.patch
>
>
> Current authentication options are heavily based on SASL and Kerberos. For
> organizations that don't already deploy Kerberos or other token provider,
> this is a heavy lift. Another very common way of authenticating in the
> industry is mTLS, which makes use of SSL certifications and can solve both
> wire encryption and auth. For those already deploying trusted certificates in
> their infra, mTLS may be much easier to integrate.
> It isn't necessarily easy to implement this, but I do think we could use
> existing Netty SSL support in the NettyRpcClient and NettyRpcServer. I know
> it's easy to add SSL to non-blocking IO through a
> hadoop.rpc.socket.factory.class.default which returns SSLSockets, but that
> doesn't touch on the certification verification at all.
> Much more investigation is needed, but logging this due to some interest
> encountered on slack.
> Slack thread:
> https://apache-hbase.slack.com/archives/C13K8NVAM/p1638980520110600
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
