[
https://issues.apache.org/jira/browse/CASSANDRA-14223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16370257#comment-16370257
]
Ron Blechman edited comment on CASSANDRA-14223 at 2/20/18 5:10 PM:
-------------------------------------------------------------------
My request is to be able to apply ANY form of customized certificate
validation, which OCSP is just one example. For example, supporting an
application that allows the user to administer what types of validation one
would like to apply (e.g. OCSP, CRLS, Host Name Validation, etc.).
In respect to OCSP, one could provide a customized Trust Manager that would
have the intelligence to know whether or not to apply OCSP checking and to what
degree (i.e. SOFT_FAIL=true or false). The benefit being that the customized
Trust Manager could do this without having to reconfigure and restart
Cassandra. Additionally, the custom Trust Manager could also determine whether
or not to provide CRL validation, hostname validation, etc.
I have found and tested that this capability can be added to Cassandra today in
a very general way through some minor code changes and the use of customized
SSLSocketFactory and SSLServerSocketFactory:
1) The customized SSLSocketFactory and SSLServerSocketFactory instantiate and
initialize an SSLContext with a customized Trust Manager and set this and are
specified in a java.security properties file.
2) Cassandra could make use of this intelligent SSLContext by a minor
modification in SSLFactory::createSSLContext().
For example:
SSLFactory::(createSSLContext():
try
{
if (Security.getProperty("ssl.SocketFactory.provider") != null
|| Security.getProperty("ssl.ServerSocketFactory.provider") != null)
{ // use default SSLContext created in the
socket factories ctx = SSLContext.getDefault(); }
else {
// use Cassandra provided SSLContext (same as before)
ctx = SSLContext.getInstance(options.protocol);
was (Author: ronblechman):
My request is to be able to apply ANY form of customized certificate
validation, which OCSP is just one example. For example, an application I am
working on allows the user to administer what types of validation one would
like to apply (e.g. OCSP, CRLS, Host Name Validation, etc.).
In respect to OCSP, one could provide a customized Trust Manager that would
have the intelligence to know whether or not to apply OCSP checking and to what
degree (i.e. SOFT_FAIL=true or false). The benefit being that the customized
Trust Manager could do this without having to reconfigure and restart
Cassandra. Additionally, the custom Trust Manager could also determine whether
or not to provide CRL validation, hostname validation, etc.
I have found and tested that this capability can be added to Cassandra today in
a very general way through some minor code changes and the use of customized
SSLSocketFactory and SSLServerSocketFactory:
1) The customized SSLSocketFactory and SSLServerSocketFactory instantiate and
initialize an SSLContext with a customized Trust Manager and set this and are
specified in a java.security properties file.
2) Cassandra could make use of this intelligent SSLContext by a minor
modification in SSLFactory::createSSLContext().
For example:
SSLFactory::(createSSLContext():
try
{
if (Security.getProperty("ssl.SocketFactory.provider") != null
|| Security.getProperty("ssl.ServerSocketFactory.provider") != null)
{
// use default SSLContext created in the socket factories
ctx = SSLContext.getDefault();
} else {
// use Cassandra provided SSLContext (same as before)
ctx = SSLContext.getInstance(options.protocol);
> Provide ability to do custom certificate validations (e.g. hostname
> validation, certificate revocation checks)
> --------------------------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-14223
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14223
> Project: Cassandra
> Issue Type: Improvement
> Components: Configuration
> Reporter: Ron Blechman
> Priority: Major
> Labels: security
> Fix For: 4.x
>
>
> Cassandra server should be to be able do additional certificate validations,
> such as hostname validatation and certificate revocation checking against
> CRLs and/or using OCSP.
> One approach couild be to have SSLFactory use SSLContext.getDefault() instead
> of forcing the creation of a new SSLContext using SSLContext.getInstance().
> Using the default SSLContext would allow a user to plug in their own custom
> SSLSocketFactory via the java.security properties file. The custom
> SSLSocketFactory could create a default SSLContext that was customized to do
> any extra validation such as certificate revocation, host name validation,
> etc.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
