[ 
https://issues.apache.org/jira/browse/CASSANDRA-14223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16477684#comment-16477684
 ] 

Jason Brown commented on CASSANDRA-14223:
-----------------------------------------

Unfortunately, your solution can only apply to the internode messaging 
connections as the native protocol is based on netty, which does not use 
{{SSLSocketFactory}} or {{SSLServerSocketFactory}} or {{SSLContext}}. Further, 
as of 4.0 everything is netty based (CASSANDRA-8457), with the exception of a 
few command line tools iirc. I'm curious if you got this to work on trunk.

Your solution does not solve the blocking problem I mentioned earlier - and, 
yes, blocking the accept thread is a problem in large clusters.

Perhaps another solution, a sort of middle ground, is to still make use of a 
custom {{TrustManager}}, but hand that to the netty {{SslContext}}, and then 
execute the TLS handshake in the netty pipeline on a different event loop group 
from the rest of the pipeline. [~ronblechman] what was the level of effort for 
you to implement the custom {{TrustManager}} that you mention? I'll do some 
research on that, as well.


> 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

Reply via email to