[
https://issues.apache.org/jira/browse/CASSANDRA-14223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16482467#comment-16482467
]
Per Otterström commented on CASSANDRA-14223:
--------------------------------------------
[~jasobrown], I'm trying to understand your concern with blocking I/O. Only
scenario I can think of is that several clients connect simultaneously and
thereby allocate (and block) so many threads that already active connections
don't get enough threads to execute requests? Not sure if that's the issue
tough. Can you elaborate a bit?
In your patch there is a comment on {{SSLSessionValidator.validate()}} that got
me confused. "This function should not block!". I thought the point of having
this separation was to allow the validator to block?
If I would like to implement hostname validation using a custom
{{SSLSessionValidator}} it think we need to change the signature of the
{{validate()}} method to {{boolean validate(SocketChannel)}}. This change would
obviously cascade to other places as well. I don't think it is possible to pull
out remote peer IP/port from a {{Channel}} object. Also, I would need to find
some way to get information from the certificate to compare. Is there some
clever way to do that?
bq. 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.
That seem like a more attractive approach IMO.
> 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
>
> Attachments: dsp.tar.gz
>
>
> 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
