[
https://issues.apache.org/jira/browse/HADOOP-13836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15702498#comment-15702498
]
kartheek muthyala edited comment on HADOOP-13836 at 11/28/16 5:03 PM:
----------------------------------------------------------------------
Yes,[~asuresh], that is exactly what we are doing here. The proposal intends to
implement an SSL layer on top of existing Hadoop RPC. It introduces SSLEngine
in Server to encode and decode messages, and uses Java's javax.net.ssl library
to encode and decode on the Client side. We have relied on niossl library for
the server side implementation of SSLEngine. Because, this implementation sits
on top of SSLSocket channel implementation, we can still keep the channels open
as before, and just encode and decode messages using the existing cipher keys.
But, as [~ste...@apache.org]pointed out, this introduces an overhead of
additional handshakes between Server and Client for different reasons like
certificate exchange, validation etc. We can trade off this performance hit
with the security that we will be enhancing. This will improve the usage of
secure IPC in large systems.
We have been running this patch internally with some long running jobs and the
performance seems to be decent. I don't have the exact numbers right away, but
I will post them soon.
was (Author: kartheek):
Yes,[~asuresh], that is exactly what we are doing here. The proposal intends to
implement an SSL layer on top of existing Hadoop RPC. It introduces SSLEngine
in Server to encode and decode messages, and Java's javax.net.ssl library to
encode and decode on the Client side. We have relied on niossl library for the
server side implementation of SSLEngine. Because, this implementation sits on
top of SSLSocket channel implementation, we can still keep the channels open as
before, and just encode and decode messages using the existing cipher keys.
But, as [~ste...@apache.org]pointed out, this introduces an overhead of
additional handshakes between Server and Client for different reasons like
certificate exchange, validation etc. We can trade off this performance hit
with the security that we will be enhancing. This will improve the usage of
secure IPC in large systems.
We have been running this patch internally with some long running jobs and the
performance seems to be decent. I don't have the exact numbers right away, but
I will post them soon.
> Securing Hadoop RPC using SSL
> -----------------------------
>
> Key: HADOOP-13836
> URL: https://issues.apache.org/jira/browse/HADOOP-13836
> Project: Hadoop Common
> Issue Type: New Feature
> Components: ipc
> Reporter: kartheek muthyala
> Attachments: HADOOP-13836.patch
>
>
> Today, RPC connections in Hadoop are encrypted using Simple Authentication &
> Security Layer (SASL), with the Kerberos ticket based authentication or
> Digest-md5 checksum based authentication protocols. This proposal is about
> enhancing this cipher suite with SSL/TLS based encryption and authentication.
> SSL/TLS is a proposed Internet Engineering Task Force (IETF) standard, that
> provides data security and integrity across two different end points in a
> network. This protocol has made its way to a number of applications such as
> web browsing, email, internet faxing, messaging, VOIP etc. And supporting
> this cipher suite at the core of Hadoop would give a good synergy with the
> applications on top and also bolster industry adoption of Hadoop.
> The Server and Client code in Hadoop IPC should support the following modes
> of communication
> 1. Plain
> 2. SASL encryption with an underlying authentication
> 3. SSL based encryption and authentication (x509 certificate)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
