[jira] [Comment Edited] (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=16479313#comment-16479313
]
Ron Blechman edited comment on CASSANDRA-14223 at 5/17/18 4:29 PM:
---
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.
+{color:#0066cc}Per Otterström{color}+ - I would need further details for me to
answer whether what you and/or [~spo...@gmail.com] are suggesting would work
for us or not. Do you know if what you are suggesting work with Bouncy Castle
in FIPS mode?
was (Author: ronblechman):
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.
+{color:#0066cc}Per Otterström{color}+ - I would need further details for me to
answer whether what you are suggesting would work for us or not. Do you know if
what you are suggesting work with Bouncy Castle in 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] [Comment Edited] (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=16479313#comment-16479313
]
Ron Blechman edited comment on CASSANDRA-14223 at 5/17/18 4:29 PM:
---
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.
+{color:#0066cc}Per Otterström{color}+ - I would need further details for me to
answer whether what you are suggesting would work for us or not. Do you know if
what you are suggesting work with Bouncy Castle in FIPS mode?
was (Author: ronblechman):
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] [Comment Edited] (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=16477546#comment-16477546
]
Jason Brown edited comment on CASSANDRA-14223 at 5/16/18 3:08 PM:
--
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
(possibly 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]
was (Author: jasobrown):
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
[jira] [Comment Edited] (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=16370684#comment-16370684
]
Ron Blechman edited comment on CASSANDRA-14223 at 2/20/18 10:38 PM:
+{color:#0066cc}Dinesh Joshi{color}+ - I am actually referring to the Cassandra
Server (see my follow-up comment above)
Consider an environment where you want mutual authentication to occur by both
Client and Server.
was (Author: ronblechman):
+{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] [Comment Edited] (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=16370257#comment-16370257
]
Ron Blechman edited comment on CASSANDRA-14223 at 2/20/18 10:33 PM:
My request is to be able to apply ANY form of customized certificate
validation, which OCSP is just one example. For example, supporting an
application that 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 here is 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 additional certificate
validations such as 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's this
customized SSLContext to be the default (i.e. sslContext.setDefault()).
The customized socket factories are added to the java.security properties file:
ssl.SocketFactory.provider=CustomSSLSocketFactory
ssl.ServerSocketFactory.provider=CustomSSLServerSocketFactory
2) Cassandra makes use of the customized 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);
...
was (Author: ronblechman):
My request is to be able to apply ANY form of customized certificate
validation, which OCSP is just one example. For example, supporting an
application that 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 here is 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 additional certificate
validations such as 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's this
customized SSLContext to be the default (i.e. sslContext.setDefault()).
The customized socket factories are added to the java.security properties file:
ssl.SocketFactory.provider=CustomSSLSocketFactory
ssl.ServerSocketFactory.provider=CustomSSLServerSocketFactory
2) Cassandra makes use of the customized 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
[jira] [Comment Edited] (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=16370257#comment-16370257
]
Ron Blechman edited comment on CASSANDRA-14223 at 2/20/18 5:31 PM:
---
My request is to be able to apply ANY form of customized certificate
validation, which OCSP is just one example. For example, supporting an
application that 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 here is 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 additional certificate
validations such as 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's this
customized SSLContext to be the default (i.e. sslContext.setDefault()).
The customized socket factories are added to the java.security properties file:
ssl.SocketFactory.provider=CustomSSLSocketFactory
ssl.ServerSocketFactory.provider=CustomSSLServerSocketFactory
2) Cassandra makes use of the customized 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);
was (Author: ronblechman):
My request is to be able to apply ANY form of customized certificate
validation, which OCSP is just one example. For example, supporting an
application that 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 here is 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 additional certificate
validations such as 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's this
customized SSLContext to be the default (i.e. sslContext.setDefault()).
The customized socket factories are added to the java.security properties file:
ssl.SocketFactory.provider=CustomSSLSocketFactory
ssl.ServerSocketFactory.provider=CustomSSLServerSocketFactory
2) Cassandra makes use of the customized 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
[jira] [Comment Edited] (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=16370257#comment-16370257
]
Ron Blechman edited comment on CASSANDRA-14223 at 2/20/18 5:29 PM:
---
My request is to be able to apply ANY form of customized certificate
validation, which OCSP is just one example. For example, supporting an
application that 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 here is 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 additional certificate
validations such as 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's this
customized SSLContext to be the default (i.e. sslContext.setDefault()).
The customized socket factories are added to the java.security properties file:
ssl.SocketFactory.provider=CustomSSLSocketFactory
ssl.ServerSocketFactory.provider=CustomSSLServerSocketFactory
2) Cassandra makes use of the customized 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);
was (Author: ronblechman):
My request is to be able to apply ANY form of customized certificate
validation, which OCSP is just one example. For example, supporting an
application that 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 here is 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 additional certificate
validations such as 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's this
customized SSLContext to be the default (i.e. sslContext.setDefault()).
The customized socket factories are added to the java.security properties file:
ssl.SocketFactory.provider=CustomSSLSocketFactory
ssl.ServerSocketFactory.provider=CustomSSLServerSocketFactory
{{2) Cassandra makes use of the customized 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:
[jira] [Comment Edited] (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=16370257#comment-16370257
]
Ron Blechman edited comment on CASSANDRA-14223 at 2/20/18 5:26 PM:
---
My request is to be able to apply ANY form of customized certificate
validation, which OCSP is just one example. For example, supporting an
application that 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 here is 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 additional certificate
validations such as 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's this
customized SSLContext to be the default (i.e. sslContext.setDefault()).
The customized socket factories are added to the java.security properties file:
ssl.SocketFactory.provider=CustomSSLSocketFactory
ssl.ServerSocketFactory.provider=CustomSSLServerSocketFactory
{{2) Cassandra makes use of the customized 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);}}
was (Author: ronblechman):
My request is to be able to apply ANY form of customized certificate
validation, which OCSP is just one example. For example, supporting an
application that 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 here is 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 additional certificate
validations such as 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's this
customized SSLContext to be the default (i.e. sslContext.setDefault()).
The customized socket factories are added to the java.security properties file:
ssl.SocketFactory.provider=CustomSSLSocketFactory
ssl.ServerSocketFactory.provider=CustomSSLServerSocketFactory
2) Cassandra makes use of the customized 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:
[jira] [Comment Edited] (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=16370257#comment-16370257
]
Ron Blechman edited comment on CASSANDRA-14223 at 2/20/18 5:24 PM:
---
My request is to be able to apply ANY form of customized certificate
validation, which OCSP is just one example. For example, supporting an
application that 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 here is 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 additional certificate
validations such as 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's this
customized SSLContext to be the default (i.e. sslContext.setDefault()).
The customized socket factories are added to the java.security properties file:
ssl.SocketFactory.provider=CustomSSLSocketFactory
ssl.ServerSocketFactory.provider=CustomSSLServerSocketFactory
2) Cassandra makes use of the customized 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);
was (Author: ronblechman):
My request is to be able to apply ANY form of customized certificate
validation, which OCSP is just one example. For example, supporting an
application that 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 here is 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 addition certificate validations such as 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's this
customized SSLContext to be the default (i.e. sslContext.setDefault()).
The customized socket factories are added to the java.security properties file:
ssl.SocketFactory.provider=CustomSSLSocketFactory
ssl.ServerSocketFactory.provider=CustomSSLServerSocketFactory
2) Cassandra makes use of the customized 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
>
>
>
[jira] [Comment Edited] (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=16370257#comment-16370257
]
Ron Blechman edited comment on CASSANDRA-14223 at 2/20/18 5:24 PM:
---
My request is to be able to apply ANY form of customized certificate
validation, which OCSP is just one example. For example, supporting an
application that 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 here is 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 addition certificate validations such as 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's this
customized SSLContext to be the default (i.e. sslContext.setDefault()).
The customized socket factories are added to the java.security properties file:
ssl.SocketFactory.provider=CustomSSLSocketFactory
ssl.ServerSocketFactory.provider=CustomSSLServerSocketFactory
2) Cassandra makes use of the customized 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);
was (Author: ronblechman):
My request is to be able to apply ANY form of customized certificate
validation, which OCSP is just one example. For example, supporting an
application that 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's this
customized SSLContext to be the default (i.e. sslContext.setDefault()).
The customized socket factories are added to the java.security properties file:
ssl.SocketFactory.provider=CustomSSLSocketFactory
ssl.ServerSocketFactory.provider=CustomSSLServerSocketFactory
2) Cassandra makes use of the customized 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
[jira] [Comment Edited] (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=16370257#comment-16370257
]
Ron Blechman edited comment on CASSANDRA-14223 at 2/20/18 5:22 PM:
---
My request is to be able to apply ANY form of customized certificate
validation, which OCSP is just one example. For example, supporting an
application that 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's this
customized SSLContext to be the default (i.e. sslContext.setDefault()).
The customized socket factories are added to the java.security properties file:
ssl.SocketFactory.provider=CustomSSLSocketFactory
ssl.ServerSocketFactory.provider=CustomSSLServerSocketFactory
2) Cassandra makes use of the customized 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);
was (Author: ronblechman):
My request is to be able to apply ANY form of customized certificate
validation, which OCSP is just one example. For example, supporting an
application that 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
[jira] [Comment Edited] (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=16370257#comment-16370257
]
Ron Blechman edited comment on CASSANDRA-14223 at 2/20/18 5:10 PM:
---
My request is to be able to apply ANY form of customized certificate
validation, which OCSP is just one example. For example, supporting an
application that 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);
was (Author: ronblechman):
My request is to be 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
>
[jira] [Comment Edited] (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=16370257#comment-16370257
]
Ron Blechman edited comment on CASSANDRA-14223 at 2/20/18 5:00 PM:
---
My request is to be 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);
was (Author: ronblechman):
My request is to be 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);
...My request is to be 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
[jira] [Comment Edited] (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=16370257#comment-16370257
]
Ron Blechman edited comment on CASSANDRA-14223 at 2/20/18 4:58 PM:
---
My request is to be 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);
...My request is to be 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);
...
was (Author: ronblechman):
My request is to be 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
[jira] [Comment Edited] (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=16370257#comment-16370257
]
Ron Blechman edited comment on CASSANDRA-14223 at 2/20/18 4:58 PM:
---
My request is to be 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);
...
was (Author: ronblechman):
My request is to be 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
[jira] [Comment Edited] (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=16370257#comment-16370257
]
Ron Blechman edited comment on CASSANDRA-14223 at 2/20/18 4:56 PM:
---
My request is to be 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);
...
was (Author: ronblechman):
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
>
