[
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: [email protected]
For additional commands, e-mail: [email protected]
