Joseph Lynch created CASSANDRA-15294:
----------------------------------------
Summary: 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
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]
