Status

Current state: Under Discussion

Discussion thread: TBD

JIRA: CASSANDRA-16666

Released: TBD

Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).

Motivation

Cassandra's adoption is growing day-by-day in the industry and it is used by all sizes of organizations serving varied technical and business domains like banking, entertainment, food/transportation logistics, financial technology to name a few. These organizations depending upon their size and domain may have more internal and external InfoSec/AppSec/Compliance standards they have to meet while using Cassanddra. SSL/TLS communication is very critical part of those standards. While Cassandra supports SSL communication sometimes it becomes challenging to use out-of-the-box solution provided by Cassandra for SSL/TLS given the organization's needs.

Currently Cassandra creates the SSLContext via SSLFactory.java. SSLFactory is a final class with static methods and not overridable. The SSLFactory loads the keys and certs from the file based artifacts for the same. While this works for many, in the industry where security is stricter and contextual, this approach falls short. Many big organizations need flexibility to load the SSL artifacts from a custom resource (like custom Key Management Solution, HashiCorp Vault, Amazon KMS etc). While JSSE SecurityProvider architecture allows us flexibility to build our custom mechanisms to validate and process security artifacts, many times all we need is to build upon Java's existing extensibility that Trust/Key Manager interfaces provide to load keystores from various resources with the absence of any customized requirements on the Keys/Certificate formats.

According to JSSE Documentation SSLContext and SSLEngine are the endpoint classes for the secure connection. Moreover, SSLEngine is created by SSLContext and can be further customized according to the needs. Hence if Cassandra provides a way to customize SSLContext it would be a great lever and provide the ultimate extensibility for the Cassandra users.

My proposal here is to make the SSLContext creation pluggable/extensible and have the current SSLFactory.java implement an extensible interface. Of course we would need to also address requirements of Hot reloading of the SSLContext, currently implemented by this class for file based keystores.

Audience

Cassandra users.

Goals

• To allow users to customize the class for SSLContext creation via Cassandra Configuration and provide complete control of how SSLContext object is created
• Keep existing functionality like cache for the SSLContext objects, periodic thread to check for hot reloading etc "as-is"

Non-Goals

• To allow plugging in custom JSSE Provider. The requirement to plugin a custom JSSE Provider is out of scope for this CIP. 
• Not sure if we need to make SSLFactory#tlsInstanceProtocolSubstituion() pluggable (Will seek guidance in the Discussion thread)

Proposed Changes

I propose following changes,

1. Create a new Java interface 'SslContextFactory'
2. Adding a new configuration like 'ssl.context.factory.class' with default value provided by newly created DefaultSslContextFactoryImpl.java
3. Create a new DefaultSslContextFactoryImpl.java implementing the new SslContextFactory interface
4. Make changes in the existing SSLFactory and other classes to use the dependency on the newly created SslContextFactory
5. Make necessary changes to the existing code to allow triggering Hotreloading on the pluggable SslContextFactory
6. Make changes in the existing EncryptionOptions.java that uses 'keystore' to determine if it needs to enable encrypted connection

New or Changed Public Interfaces

New configuration

ssl.context.factory.class

New SslContextFactory interface

package org.apache.cassandra.security;

import javax.net.ssl.SSLContext;

import io.netty.handler.ssl.CipherSuiteFilter;
import io.netty.handler.ssl.SslContext;
import org.apache.cassandra.config.EncryptionOptions;

/**
 * The purpose of this interface is to provide pluggable mechanism for creating JSSE and Netty SSLContext objects.
 * Please use the Cassandra configuration key {@code ssl.context.factory.class} and provide a custom class-name
 * implementing this interface to plugin a your own way to load the SSLContext.
 *
 * Since on top of Netty, Cassandra is internally using JSSE SSLContext also for certain use-cases- this interface
 * has methods for both.
 */
public interface SslContextFactory
{
    /**
     * Creates JSSE SSLContext.
     *
     * @param options EncryptionOptions that could be used for the SSL context creation
     * @param buildTruststore {@code true} if the caller requires Truststore; {@code false} otherwise
     * @return
     */
    SSLContext createJSSESslContext(EncryptionOptions options, boolean buildTruststore);

    /**
     * Creates Netty's SslContext object.
     *
     * @param options EncryptionOptions that could be used for the SSL context creation
     * @param buildTruststore {@code true} if the caller requires Truststore; {@code false} otherwise
     * @param socketType {@link SocketType} for Netty's Inbound or Outbound channels
     * @param cipherFilter to allow Netty's cipher suite filtering, e.g.
     * {@link io.netty.handler.ssl.SslContextBuilder#ciphers(Iterable, CipherSuiteFilter)}
     * @return
     */
    SslContext createNettySslContext(EncryptionOptions options, boolean buildTruststore, SocketType socketType,
                                     CipherSuiteFilter cipherFilter);

    /**
     * Returns if any changes require the reloading of the SSL context returned by this factory.
     * This will be called by Cassandra's periodic polling for any potential changes that will reload the SSL context
     * . However only newer connections established after the reload will use the reloaded SSL context.
     * @return
     */
    boolean shouldReload();

    /**
     * SocketType to differentiate Server and Client. This is primarily used for Netty's Inbound and Outbound channels.
     */
    enum SocketType {
        SERVER, CLIENT;
    }
}

Compatibility, Deprecation, and Migration Plan

• What impact (if any) will there be on existing users?

No impact expected by existing users. Default implementation of SslContextFactory will ensure existing functionality is kept intact.

• If we are changing behavior how will we phase out the older behavior?

No need to phase out older behavior.

• If we need special migration tools, describe them here.

Not applicable

• When will we remove the existing behavior?

Not applicable

Test Plan

• Successful integration tests
• Successful local system test to use existing mechanism for the keystores and make sure the default SslContextFactory works for JSSE and Netty SSL Context creation
• For any additional requirements from the Cassandra community, will seek guidance on the discussion thread

Rejected Alternatives

Modify existing SSLFactory to allow custom mechanism to load keystores only

If we allow custom mechanism to load keystores from any source, it could still limit ability to customize other parameters in the SSLContext. This could become a limitation for a use-case. Delegating the creation of the whole SSLContext object is more flexible approach that can fit variety of use-cases.