[jira] [Commented] (CASSANDRA-14223) Provide ability to do custom certificate validations (e.g. hostname validation, certificate revocation checks)

["Jason Brown (JIRA)" <ji...@apache.org>]

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

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

bq. It is already possible to use your own trust manager implementation that will validate certificates using your custom validation logic

This is possible, but runs afowl of performing all that custom validation (think blocking IO, including remote network calls!) on either the accept thread (pre-4.0) or on a netty event loop thread (blocking any other established pipelines on that thread within the event loop group). 

Below is a patch that allows a user to write a class (implmenting a new {{SSLSessionValidator}} interface), and have it execute as part of the set up/initialization of an inbound netty pipeline (both native protocol and internode messaging).

The {{SSLSessionValidator}} instance is wrapped by a netty handler ({{CustomSslValidationHandler}}), and executed in a distinct {{EventLoopGroup}} within the netty pipeline to isolate any behavior (especially blocking IO) from affecting any other network activity (reads/writes).

The patch below is half-PoC, half complete. The naming is a little inconsistent, and I wanted input on that. If this looks promising, I'll finish it up and add tests. Also, I'll need an example implementation in the code base, but I'm not sure of the best location ({{examples/}}, {{tests/}}, ?)  

||14223||
|[branch|https://github.com/jasobrown/cassandra/tree/14223]|

One disadvantage to my solution is that, I think, OCSP stapling might not be possible as the TLS handshake has already completed (within netty's {{SslHandler}}) before it would get to the {{CustomSslValidationHandler}} in the pipeline. [~djoshi3] can you corroborate this?

Also, I'm not sure what the level of effort for implementing a custom {{TrustManager}} might be. It's unclear if that would be easier or more difficult than my proposed solution. Thoughts? /cc [~spodxx@gmail.com] [~eperott]


> 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