[CASSANDRA-15294] Allow easy use of custom security providers

• Type: Improvement
• Status: Resolved
• Priority: Normal
• Resolution: Fixed
• Component/s: Local/Config
• Platform: All
• Impacts: Security
• Assignee: Unassigned
• Reporter: Joey Lynch
• Created: 28/Aug/19 20:54
• Updated: 30/May/24 17:00
• Resolved: 30/May/24 04:04

Description

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). 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 and recently Amazon's ACCP 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 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.

Issue Links

• is cloned by: CASSANDRA-18624 Make Corretto Crypto Provider the Default
• is related to: CASSANDRA-18624 Make Corretto Crypto Provider the Default