[
https://issues.apache.org/jira/browse/HBASE-16414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15449418#comment-15449418
]
Andrew Purtell edited comment on HBASE-16414 at 8/30/16 4:16 PM:
-----------------------------------------------------------------
I'm sorry but we can't accept this patch as-is.
The naming of classes, like SaslAES and SaslCipherMeta and such use the term
SASL but this isn't appropriate here. SASL is a standard. What this patch
proposes is injection of custom negotiation (using protobuf of custom
construction) and encryption that have nothing to do with the SASL standard.
The naming of these classes is a lie and proposed integration is not clean.
Ram's suggestion to unify this code with the SASL code in the RPC server cannot
achieve a good result because fundamentally this has nothing to do with SASL.
While I have to veto this current proposal I do think accelerated AES
encryption for HBase RPC would be good to have.
My suggestion for a path forward is to integrate the accelerated codec below
HBase in the JRE's SASL stack. Implement a SASL security provider
(https://docs.oracle.com/javase/8/docs/technotes/guides/security/sasl/sasl-refguide.html#PROV).
Then there should be no custom messages or API needed at the HBase layer. The
changes needed would be to add configuration that tells HBase to request and
use the custom provider by setting the right system properties as defined by
the Java SASL API and ask the provider to negotiate (via the SASL standard
protocols...) the desired custom mechanism.
Another possible path forward is to implement connection parameter negotiation
like as proposed on HBASE-9351. Then the integration will be good. We can
extend our protocol with new options such as this cleanly without abusing (at
best) the meaning of names and labels in the code.
was (Author: apurtell):
I'm sorry but we can't accept this patch as-is.
The naming of classes, like SaslAES and SaslCipherMeta and such use the term
SASL but this isn't appropriate here. SASL is a standard. What this patch
proposes is injection of custom negotiation (using protobuf of custom
construction) and encryption that have nothing to do with the SASL standard.
The naming of these classes is a lie and proposed integration is not clean.
Ram's suggestion to unify this code with the SASL code in the RPC server cannot
achieve a good result because fundamentally this has nothing to do with SASL.
While I have to veto this current proposal I do think accelerated AES
encryption for HBase RPC would be good to have.
My suggestion for a path forward is to integrate the accelerated codec below
HBase in the JRE's SASL stack. Implement a SASL security provider
(https://docs.oracle.com/javase/8/docs/technotes/guides/security/sasl/sasl-refguide.html#PROV).
Then there should be no custom messages or API needed at the HBase layer. The
changes needed would be to add configuration that tells HBase to request and
use the custom provider by setting the right system properties as defined by
the Java SASL API.
Another possible path forward is to implement connection parameter negotiation
like as proposed on HBASE-9351. Then the integration will be good. We can
extend our protocol with new options such as this cleanly without abusing (at
best) the meaning of names and labels in the code.
> Improve performance for RPC encryption with Apache Common Crypto
> ----------------------------------------------------------------
>
> Key: HBASE-16414
> URL: https://issues.apache.org/jira/browse/HBASE-16414
> Project: HBase
> Issue Type: Improvement
> Components: IPC/RPC
> Affects Versions: 2.0.0
> Reporter: Colin Ma
> Assignee: Colin Ma
> Attachments: HBASE-16414.001.patch, HbaseRpcEncryptionWithCrypoto.docx
>
>
> Hbase RPC encryption is enabled by setting “hbase.rpc.protection” to
> "privacy". With the token authentication, it utilized DIGEST-MD5 mechanisms
> for secure authentication and data protection. For DIGEST-MD5, it uses DES,
> 3DES or RC4 to do encryption and it is very slow, especially for Scan. This
> will become the bottleneck of the RPC throughput.
> Apache Commons Crypto is a cryptographic library optimized with AES-NI. It
> provides Java API for both cipher level and Java stream level. Developers can
> use it to implement high performance AES encryption/decryption with the
> minimum code and effort. Compare with the current implementation of
> org.apache.hadoop.hbase.io.crypto.aes.AES, Crypto supports both JCE Cipher
> and OpenSSL Cipher which is better performance than JCE Cipher. User can
> configure the cipher type and the default is JCE Cipher.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
