[jira] [Commented] (CASSANDRA-14223) Provide ability to do custom certificate validations (e.g. hostname validation, certificate revocation checks)
[
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
[jira] [Commented] (CASSANDRA-14223) Provide ability to do custom certificate validations (e.g. hostname validation, certificate revocation checks)
[ https://issues.apache.org/jira/browse/CASSANDRA-14223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16482416#comment-16482416 ] Per Otterström commented on CASSANDRA-14223: Attached dsp.tar.gz. A minimal security provider, only containing a single service - a TrustManager with enforced hostname validation. There is a readme with some instructions on how to use it. [~ronblechman], based on what you described around your tests, I believe that you should be able to install your own TrustManager in a similar way. Bouncy Castle seem to support a similar setup: [http://www.bouncycastle.org/wiki/display/JA1/Provider+Installation] What I like about this approach, is that I can install and manage my security providers in the same way for all my Java based applications. > 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
[jira] [Commented] (CASSANDRA-14223) Provide ability to do custom certificate validations (e.g. hostname validation, certificate revocation checks)
[ https://issues.apache.org/jira/browse/CASSANDRA-14223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16479313#comment-16479313 ] Ron Blechman commented on CASSANDRA-14223: -- I haven't tried this on the 4.0 trunk. I have been working solely with Cassandra 3.11.2. and have been testing this with CRLs that are pre-fetched - which I believe avoids the concerns you mentioned about blocking. My comments about OCSP are looking more towards the future - as my first priority is to have this work with CRLs. I have tested this with OCSP and dynamically downloaded CRLS, but perhaps not rigorously enough to run into the issues you expressed concern about. > 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
[jira] [Commented] (CASSANDRA-14223) Provide ability to do custom certificate validations (e.g. hostname validation, certificate revocation checks)
[ https://issues.apache.org/jira/browse/CASSANDRA-14223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16479108#comment-16479108 ] Per Otterström commented on CASSANDRA-14223: It's fairly straight forward to create a custom TrustManager. I could create a simplistic example to demonstrate. We're installing custom trust managers in our deployments at Ericsson using the procedure that [~spo...@gmail.com] described above. I don't think we should invent our own way to achieve this, when there is a standardized way. [~ronblechman] I believe you should be able to achieve what you want using this procedure. Rigth? Currently it is not possible to get hostname validation (custom TrustManager or not), but that should be solved by CASSANDRA-13404 if we agree to merge it. [~jasobrown] I'm not sure I share your concern. A custom TrustManager could maintain internal state, such as updating lists of revoced certificates, in a separete thread, right? It doesn't have to happen on the accept-thread/event-loop-thread? I will have a look at your patch to better understand. > 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
[jira] [Commented] (CASSANDRA-14223) Provide ability to do custom certificate validations (e.g. hostname validation, certificate revocation checks)
[
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
[jira] [Commented] (CASSANDRA-14223) Provide ability to do custom certificate validations (e.g. hostname validation, certificate revocation checks)
[ https://issues.apache.org/jira/browse/CASSANDRA-14223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16477584#comment-16477584 ] Ron Blechman commented on CASSANDRA-14223: -- The simple solution I mentioned above of providing access to a customized SSLContext with revocation checking is working for both CRL and OCSP simply by having Cassandra call SSLContext.getDefault(). > 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
[jira] [Commented] (CASSANDRA-14223) Provide ability to do custom certificate validations (e.g. hostname validation, certificate revocation checks)
[
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 [~spo...@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-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14223) Provide ability to do custom certificate validations (e.g. hostname validation, certificate revocation checks)
[ https://issues.apache.org/jira/browse/CASSANDRA-14223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16371518#comment-16371518 ] Ron Blechman commented on CASSANDRA-14223: -- I'm not sure the approach of using one's own security provider will work in a FIPS environment (e.g. Bouncy Castle FIPS mode)? > 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
[jira] [Commented] (CASSANDRA-14223) Provide ability to do custom certificate validations (e.g. hostname validation, certificate revocation checks)
[ https://issues.apache.org/jira/browse/CASSANDRA-14223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16371424#comment-16371424 ] Jeremiah Jordan commented on CASSANDRA-14223: - I can confirm that the above works to do custom SSL validations in Cassandra. I have done exactly that in the past. > 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
[jira] [Commented] (CASSANDRA-14223) Provide ability to do custom certificate validations (e.g. hostname validation, certificate revocation checks)
[
https://issues.apache.org/jira/browse/CASSANDRA-14223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16371205#comment-16371205
]
Stefan Podkowinski commented on CASSANDRA-14223:
It is already possible to use your own trust manager implementation that will
validate certificates using your custom validation logic. You'll have to
register your own security provider in {{java.security}}. The provider needs to
specify your TrustManagerFactorySpi implementation using a specific algorithm
name that you afterwards have to set as
{{server_encryption_options.algorithms}} in {{cassandra.yaml}}. But this should
not involve any SSLSocket code related changes and is not really Cassandra
specific at all.
> 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
[jira] [Commented] (CASSANDRA-14223) Provide ability to do custom certificate validations (e.g. hostname validation, certificate revocation checks)
[
https://issues.apache.org/jira/browse/CASSANDRA-14223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16370684#comment-16370684
]
Ron Blechman commented on CASSANDRA-14223:
--
+{color:#0066cc}Dinesh Joshi{color}+ - I am actually referring to the Cassandra
Server (see my follow-up comment above)
> 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
[jira] [Commented] (CASSANDRA-14223) Provide ability to do custom certificate validations (e.g. hostname validation, certificate revocation checks)
[
https://issues.apache.org/jira/browse/CASSANDRA-14223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16370257#comment-16370257
]
Ron Blechman commented on CASSANDRA-14223:
--
My request is in respecct to being able to apply ANY form of customized
certificate validation, which OCSP is just one example. For example, an
application I am working on 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 being 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 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 this and are
specified in a java.security properties file.
2) Cassandra could make use of this intelligent 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-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14223) Provide ability to do custom certificate validations (e.g. hostname validation, certificate revocation checks)
[ https://issues.apache.org/jira/browse/CASSANDRA-14223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16360330#comment-16360330 ] Dinesh Joshi commented on CASSANDRA-14223: -- [~ronblechman], could you please expand on OCSP? Specifically - are you looking for the clients to verify the Server's certificate expiry or vice-versa? Or are you interested in both Server, Client verifying each other's certificate expiry? From a scalability standpoint OCSP Stapling is essential. Support for it is coming in Java 9 (see [JEP 249|http://openjdk.java.net/jeps/249]). What do expect to be added to C* for OCSP? > 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 > Fix For: 3.11.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
