cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ron Blechman (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-14223) Provide ability to do custom certificate validations (e.g. hostname validation, certificate revocation checks)
Date Tue, 20 Feb 2018 17:27:00 GMT

    [ 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:26 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 here is 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 additional certificate validations such as 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's this customized SSLContext to
be the default  (i.e. sslContext.setDefault()).
 The customized socket factories are added to the java.security properties file:
 ssl.SocketFactory.provider=CustomSSLSocketFactory
 ssl.ServerSocketFactory.provider=CustomSSLServerSocketFactory

{{2) Cassandra makes use of the customized 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, 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 here is 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 additional certificate validations such as 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's this customized SSLContext to
be the default  (i.e. sslContext.setDefault()).
 The customized socket factories are added to the java.security properties file:
 ssl.SocketFactory.provider=CustomSSLSocketFactory
 ssl.ServerSocketFactory.provider=CustomSSLServerSocketFactory

2) Cassandra makes use of the customized 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-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org


Mime
View raw message