[
https://issues.apache.org/jira/browse/KAFKA-4050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15423390#comment-15423390
]
ASF GitHub Bot commented on KAFKA-4050:
---------------------------------------
GitHub user toddpalino opened a pull request:
https://github.com/apache/kafka/pull/1747
KAFKA-4050: Allow configuration of the PRNG used for SSL
Add an optional configuration for the SecureRandom PRNG implementation,
with the default behavior being the same (use the default implementation in the
JDK/JRE).
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/toddpalino/kafka trunk
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/kafka/pull/1747.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #1747
----
commit 4d101bdf5faf58fb2e0e54c0848133cc9deda6ef
Author: Todd Palino <todd palino>
Date: 2016-08-16T20:58:34Z
Make the SecureRandom implementation configurable
commit 4793b69b3287b0f4fc8905aa62608e5b64f57f90
Author: Todd Palino <todd palino>
Date: 2016-08-16T20:58:52Z
Add a note in the docs about setting the SecureRandom PRNG implementation
----
> Allow configuration of the PRNG used for SSL
> --------------------------------------------
>
> Key: KAFKA-4050
> URL: https://issues.apache.org/jira/browse/KAFKA-4050
> Project: Kafka
> Issue Type: Improvement
> Components: security
> Affects Versions: 0.10.0.1
> Reporter: Todd Palino
> Assignee: Todd Palino
> Labels: security, ssl
>
> This change will make the pseudo-random number generator (PRNG)
> implementation used by the SSLContext configurable. The configuration is not
> required, and the default is to use whatever the default PRNG for the JDK/JRE
> is. Providing a string, such as "SHA1PRNG", will cause that specific
> SecureRandom implementation to get passed to the SSLContext.
> When enabling inter-broker SSL in our certification cluster, we observed
> severe performance issues. For reference, this cluster can take up to 600
> MB/sec of inbound produce traffic over SSL, with RF=2, before it gets close
> to saturation, and the mirror maker normally produces about 400 MB/sec
> (unless it is lagging). When we enabled inter-broker SSL, we saw persistent
> replication problems in the cluster at any inbound rate of more than about 6
> or 7 MB/sec per-broker. This was narrowed down to all the network threads
> blocking on a single lock in the SecureRandom code.
> It turns out that the default PRNG implementation on Linux is NativePRNG.
> This uses randomness from /dev/urandom (which, by itself, is a non-blocking
> read) and mixes it with randomness from SHA1. The problem is that the entire
> application shares a single SecureRandom instance, and NativePRNG has a
> global lock within the implNextBytes method. Switching to another
> implementation (SHA1PRNG, which has better performance characteristics and is
> still considered secure) completely eliminated the bottleneck and allowed the
> cluster to work properly at saturation.
> The SSLContext initialization has an optional argument to provide a
> SecureRandom instance, which the code currently sets to null. This change
> creates a new config to specify an implementation, and instantiates that and
> passes it to SSLContext if provided. This will also let someone select a
> stronger source of randomness (obviously at a performance cost) if desired.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
