[
https://issues.apache.org/jira/browse/CASSANDRA-15294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joseph Lynch updated CASSANDRA-15294:
-------------------------------------
Impacts: Security (was: None)
> Allow easy use of custom security providers
> -------------------------------------------
>
> Key: CASSANDRA-15294
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15294
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
> Reporter: Joseph Lynch
> Priority: Normal
>
> As more users are switching to using {{AES-GCM}} TLS they are increasingly
> running into extremely poor performance with the JDK implementations (e.g.
> [JDK-8046943|https://bugs.openjdk.java.net/browse/JDK-8046943]). It's not
> just TLS either, generally speaking Java crypto can be really slow, including
> for example MD5 hashing which powers our digests (CASSANDRA-14611).
> There have been a few community attempts to fix this via customer java
> security providers, for example Google's
> [conscrypt|https://github.com/google/conscrypt] and recently Amazon's
> [ACCP|https://github.com/corretto/amazon-corretto-crypto-provider] which are
> basically portions of OpenSSL/BoringSSL that are statically linked in and
> exposed via JNI. These approaches are similar in spirit to what
> [netty-tcnative|https://github.com/netty/netty-tcnative] is doing for TLS in
> C* trunk.
> Since there may be tradeoffs to using various providers for various functions
> (e.g. {{conscrypt}} may be faster or slower than {{accp}} in certain use
> cases and in other cases you may want to use JDK providers for ease of
> upgrading) it would be useful if Cassandra supported pluggable providers per
> use case. For example we could use {{conscrypt}} for TLS, {{accp}} for MD5
> digesting, and the {{SUN}} provider for everything else. There is a small
> amount of JVM wiring that needs to be done for this and it could unlock
> 10-25% CPU capacity improvements.
> We can then use this pluggability to test different providers and if one is
> strictly dominant we can just check that one in in libs and default to it.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
