[jira] [Comment Edited] (CASSANDRA-18778) Empty keystore_password no longer allowed on encryption_options
[ https://issues.apache.org/jira/browse/CASSANDRA-18778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17762263#comment-17762263 ] Maulin Vasavada edited comment on CASSANDRA-18778 at 9/6/23 4:31 AM: - Hi [~andrew.tolbert] [~smiklosovic] sorry I am late looking at this but I read the details here. Interestingly when we did CASSANDRA-18124 changes, we did talk about this exact issue- What to do with password check for the JKS based keystores- as you would be able to notice in that ticket, !image-2023-09-05-21-13-06-602.png! So at that point we decided to go with enforcing the JKS keystores to have the password. However, based on what [~andrew.tolbert] mentions here about PKCS12 keystores generated without a password via OpenSSL makes a valid case in terms of `What tools allow?`. In the Keytool/Java it clearly gives a warning when we read keystores without a password that the authenticity of the data can't be verified without the password and that made me think about the password's necessity for the JKS keystores. So while from the operational standpoint I would still think we should specify password for the keystore, if the tooling from OpenSSL allows passwordless keystore creation, we can make this exception to cover for it. For the Truststores, however I think we can live without password since it is just a collection of `public keys` and authenticity like keystore may be considered optional. That was the primary thinking that resulted into the state of code that we have prior to this change. One challenge, if I recollect it right, I ran into was- in the YAML file I could not simulate the `null` password because there was a default of `empty string` somewhere (most likely EncryptionOptions.java). Based on what I see in your changes that got merged- I see that you are testing for `null` case from the code and not from the YAML. Just something to double-click on and see if there is anything we need to do more. If practically YAML file makes it difficult to have a possibility of `null` password, the CASSANDRA-18124 should not create a backward incompatibility issue in my opinion. All-in-all, I don't mind having to support keystores without passwords and don't feel it may be worth requiring passwords for the truststores :) was (Author: maulin.vasavada): Hi [~andrew.tolbert] [~smiklosovic] sorry I am late looking at this but I read the details here. Interestingly when we did CASSANDRA-18124 changes, we did talk about this exact issue- What to do with password check for the JKS based keystores- as you would be able to notice in that ticket, !image-2023-09-05-21-13-06-602.png! So at that point we decided to go with enforcing the JKS keystores to have the password. However, based on what [~andrew.tolbert] mentions here about PKCS12 keystores generated without a password via OpenSSL makes a valid case in terms of `What tools allow?`. In the Keytool/Java it clearly gives a warning when we read keystores without a password that the authenticity of the data can't be verified without the password and that made me think about the password's necessity for the JKS keystores. So while from the operational standpoint I would still think we should specify password for the keystore, if the tooling from OpenSSL allows passwordless keystore creation, we can make this exception to cover for it. For the Truststores, however I think we can live without password since it is just a collection of `public keys` and authenticity like keystore may be considered optional. That was the primary thinking that resulted into the state of code that we have prior to this change. One challenge, if I recollect it right, I ran into was- in the YAML file I could not simulate the `null` password because there was a default of `empty string` somewhere (most likely EncryptionOptions.java). Based on what I see in your changes that got merged- I see that you are testing for `null` case from the code and not from the YAML. Just something to double-click on and see if there is anything we need to do more. All-in-all, I don't mind having to support keystores without passwords and don't feel it may be worth requiring passwords for the truststores :) > Empty keystore_password no longer allowed on encryption_options > --- > > Key: CASSANDRA-18778 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18778 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Andy Tolbert >Assignee: Andy Tolbert >Priority: Normal > Fix For: 4.1.4, 5.0 > > Attachments: image-2023-09-05-21-13-06-602.png > > > After CASSANDRA-18124 (introduced in 4.1.2 and 5.0) it is no longer possible > t
[jira] [Comment Edited] (CASSANDRA-18778) Empty keystore_password no longer allowed on encryption_options
[
https://issues.apache.org/jira/browse/CASSANDRA-18778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17762263#comment-17762263
]
Maulin Vasavada edited comment on CASSANDRA-18778 at 9/6/23 4:28 AM:
-
Hi [~andrew.tolbert] [~smiklosovic] sorry I am late looking at this but I read
the details here. Interestingly when we did CASSANDRA-18124 changes, we did
talk about this exact issue- What to do with password check for the JKS based
keystores- as you would be able to notice in that ticket,
!image-2023-09-05-21-13-06-602.png!
So at that point we decided to go with enforcing the JKS keystores to have the
password. However, based on what [~andrew.tolbert] mentions here about PKCS12
keystores generated without a password via OpenSSL makes a valid case in terms
of `What tools allow?`. In the Keytool/Java it clearly gives a warning when we
read keystores without a password that the authenticity of the data can't be
verified without the password and that made me think about the password's
necessity for the JKS keystores. So while from the operational standpoint I
would still think we should specify password for the keystore, if the tooling
from OpenSSL allows passwordless keystore creation, we can make this exception
to cover for it.
For the Truststores, however I think we can live without password since it is
just a collection of `public keys` and authenticity like keystore may be
considered optional. That was the primary thinking that resulted into the state
of code that we have prior to this change.
One challenge, if I recollect it right, I ran into was- in the YAML file I
could not simulate the `null` password because there was a default of `empty
string` somewhere (most likely EncryptionOptions.java). Based on what I see in
your changes that got merged- I see that you are testing for `null` case from
the code and not from the YAML. Just something to double-click on and see if
there is anything we need to do more.
All-in-all, I don't mind having to support keystores without passwords and
don't feel it may be worth requiring passwords for the truststores :)
was (Author: maulin.vasavada):
Hi [~andrew.tolbert] [~smiklosovic] sorry I am late looking at this but I read
the details here. Interestingly when we did CASSANDRA-18124 changes, we did
talk about this exact issue- What to do with password check for the JKS based
keystores- as you would be able to notice in that ticket,
!image-2023-09-05-21-13-06-602.png!
So at that point we decided to go with enforcing the JKS keystores to have the
password. However, based on what [~andrew.tolbert] mentions here about PKCS12
keystores generated without a password via OpenSSL makes a valid case in terms
of `What tools allows`. In the Keytool it clearly gives a warning when we read
keystores without a password that the authenticity of the data can't be
verified without the password and that made me think about the password's
necessity for the JKS keystores. So while from the operational standpoint I
would still think we should specify password for the keystore, if the tooling
from OpenSSL allows passwordless keystore creation, we can make this exception.
For the Truststores, however I think we can live without password since it is
just a collection of `public keys` and authenticity like keystore may be
considered optional. That was the primary thinking that resulted into the state
of code that we have prior to this change.
One challenge, if I recollect it right, I ran into was- in the YAML file I
could not simulate the `null` password because there was a default of `empty
string` somewhere (most likely EncryptionOptions.java). Based on what I see in
your changes that got merged- I see that you are testing for `null` case from
the code and not from the YAML. Just something to double-click on and see if
there is anything we need to do more.
All-in-all, I don't mind having to support keystores without passwords and
don't feel it may be worth requiring passwords for the truststores :)
> Empty keystore_password no longer allowed on encryption_options
> ---
>
> Key: CASSANDRA-18778
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18778
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 4.1.4, 5.0
>
> Attachments: image-2023-09-05-21-13-06-602.png
>
>
> After CASSANDRA-18124 (introduced in 4.1.2 and 5.0) it is no longer possible
> to set an empty {{keystore_password}} under {{client_encryption_options}} or
> {{server_encryption_options}} using the default implementation
> {{{}DefaultSslContextFactory{}}}.
> While keytool d
[jira] [Comment Edited] (CASSANDRA-18778) Empty keystore_password no longer allowed on encryption_options
[
https://issues.apache.org/jira/browse/CASSANDRA-18778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17762263#comment-17762263
]
Maulin Vasavada edited comment on CASSANDRA-18778 at 9/6/23 4:27 AM:
-
Hi [~andrew.tolbert] [~smiklosovic] sorry I am late looking at this but I read
the details here. Interestingly when we did CASSANDRA-18124 changes, we did
talk about this exact issue- What to do with password check for the JKS based
keystores- as you would be able to notice in that ticket,
!image-2023-09-05-21-13-06-602.png!
So at that point we decided to go with enforcing the JKS keystores to have the
password. However, based on what [~andrew.tolbert] mentions here about PKCS12
keystores generated without a password via OpenSSL makes a valid case in terms
of `What tools allows`. In the Keytool it clearly gives a warning when we read
keystores without a password that the authenticity of the data can't be
verified without the password and that made me think about the password's
necessity for the JKS keystores. So while from the operational standpoint I
would still think we should specify password for the keystore, if the tooling
from OpenSSL allows passwordless keystore creation, we can make this exception.
For the Truststores, however I think we can live without password since it is
just a collection of `public keys` and authenticity like keystore may be
considered optional. That was the primary thinking that resulted into the state
of code that we have prior to this change.
One challenge, if I recollect it right, I ran into was- in the YAML file I
could not simulate the `null` password because there was a default of `empty
string` somewhere (most likely EncryptionOptions.java). Based on what I see in
your changes that got merged- I see that you are testing for `null` case from
the code and not from the YAML. Just something to double-click on and see if
there is anything we need to do more.
All-in-all, I don't mind having to support keystores without passwords and
don't feel it may be worth requiring passwords for the truststores :)
was (Author: maulin.vasavada):
Hi [~andrew.tolbert] [~smiklosovic] sorry I am late looking at this but I read
the details here. Interestingly when we did CASSANDRA-18124 changes, we did
talk about this exact issue- What to do with password check for the JKS based
keystores- as you would be able to notice in that ticket,
!image-2023-09-05-21-13-06-602.png!
So at that point we decided to go with enforcing the JKS keystores to have the
password. However, based on what [~andrew.tolbert] mentions here about PKCS12
keystores generated without a password via OpenSSL makes a valid case in terms
of `What tools allows`. In the Keytool it clearly gives a warning when we read
keystores without a password that the authenticity of the data can't be
verified without the password and that made me think about the password's
necessity for the JKS keystores. So while from the operational standpoint I
would still think we should specify password for the keystore, if the tooling
from OpenSSL allows passwordless keystore creation, we can make this exception.
For the Truststores, however I think we can live without password since it is
just a collection of `public keys` and authenticity like keystore may be
considered optional. That was the primary thinking that resulted into the state
of code that we have prior to this change.
One challenge, if I recollect it right, I ran into was- in the YAML file I
could not simulate the `null` password because there was a default of `empty
string` somewhere (most likely EncryptionOptions.java). However, if your
changes are tested already and merged I guess you have a test case for
differentiating `null` vs `empty string` (will check your PR).
All-in-all, I don't mind having to support keystores without passwords and
don't feel it may be worth requiring passwords for the truststores :)
> Empty keystore_password no longer allowed on encryption_options
> ---
>
> Key: CASSANDRA-18778
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18778
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 4.1.4, 5.0
>
> Attachments: image-2023-09-05-21-13-06-602.png
>
>
> After CASSANDRA-18124 (introduced in 4.1.2 and 5.0) it is no longer possible
> to set an empty {{keystore_password}} under {{client_encryption_options}} or
> {{server_encryption_options}} using the default implementation
> {{{}DefaultSslContextFactory{}}}.
> While keytool does not allow generating keystores with empty passwords, it
> does s
[jira] [Comment Edited] (CASSANDRA-18778) Empty keystore_password no longer allowed on encryption_options
[
https://issues.apache.org/jira/browse/CASSANDRA-18778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17758862#comment-17758862
]
Stefan Miklosovic edited comment on CASSANDRA-18778 at 8/25/23 7:43 AM:
[~andrew.tolbert]
as I am reading that patch ... what about truststores? Should not we apply same
logic there?
I built it all one more time on more recent branches:
[4.1
j11|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3008/workflows/374c4d90-ff16-414f-b1e1-3dd7974bfd22]
[4.1
j8|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3008/workflows/85477c44-162e-4fab-9d17-f0efd7af5fef]
[5.0
j17|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3013/workflows/2bd35adf-87ea-4bf8-88d4-1005c80ce999]
[5.0
j11|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3013/workflows/9d8d83dd-f283-4ec8-a9ff-43f410801ced]
[trunk
j17|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3012/workflows/699cf0d5-fb26-4c76-8e46-48db627aaec6]
[trunk
j11|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3012/workflows/1dfba849-060f-4440-90ef-1349e937d2f2]
was (Author: smiklosovic):
+1 from me too.
I built it all one more time on more recent branches:
[4.1
j11|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3008/workflows/374c4d90-ff16-414f-b1e1-3dd7974bfd22]
[4.1
j8|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3008/workflows/85477c44-162e-4fab-9d17-f0efd7af5fef]
[5.0
j17|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3013/workflows/2bd35adf-87ea-4bf8-88d4-1005c80ce999]
[5.0
j11|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3013/workflows/9d8d83dd-f283-4ec8-a9ff-43f410801ced]
[trunk
j17|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3012/workflows/699cf0d5-fb26-4c76-8e46-48db627aaec6]
[trunk
j11|https://app.circleci.com/pipelines/github/instaclustr/cassandra/3012/workflows/1dfba849-060f-4440-90ef-1349e937d2f2]
> Empty keystore_password no longer allowed on encryption_options
> ---
>
> Key: CASSANDRA-18778
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18778
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 4.1.x, 5.0.x
>
>
> After CASSANDRA-18124 (introduced in 4.1.2 and 5.0) it is no longer possible
> to set an empty {{keystore_password}} under {{client_encryption_options}} or
> {{server_encryption_options}} using the default implementation
> {{{}DefaultSslContextFactory{}}}.
> While keytool does not allow generating keystores with empty passwords, it
> does support reading them. It is not uncommon to use PKCS12 certificates
> generated by other tools (eg. openssl) that do not enforce passwords.
> The fix for this should be pretty straightforward, which should involve
> changing
> [FileBasedSslContextFactory.validatePassword|https://github.com/apache/cassandra/blob/cassandra-4.1.2/src/java/org/apache/cassandra/security/FileBasedSslContextFactory.java#L128-L135]
> to only disallow null passwords (which would be consistent with previous
> versions). I will create pull requests against the relevant branches shortly.
> {noformat}
> Exception (org.apache.cassandra.exceptions.ConfigurationException)
> encountered during startup: Failed to initialize SSL
> org.apache.cassandra.exceptions.ConfigurationException: Failed to initialize
> SSL
> at
> org.apache.cassandra.config.DatabaseDescriptor.applySslContext(DatabaseDescriptor.java:1155)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applyAll(DatabaseDescriptor.java:390)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:204)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:188)
> at
> org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:804)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:747)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:875)
> Caused by: java.io.IOException: Failed to create SSL context using Native
> transport
> at
> org.apache.cassandra.security.SSLFactory.validateSslContext(SSLFactory.java:405)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applySslContext(DatabaseDescriptor.java:1150)
> ... 6 more
> Caused by: java.lang.IllegalArgumentException: 'keystore_password' must be
> specified
> at
> org.apache.cassandra.security.FileBasedSslContextFactory.validatePassword(FileBasedSslContextFactory.java:133)
>
[jira] [Comment Edited] (CASSANDRA-18778) Empty keystore_password no longer allowed on encryption_options
[
https://issues.apache.org/jira/browse/CASSANDRA-18778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757655#comment-17757655
]
Andy Tolbert edited comment on CASSANDRA-18778 at 8/22/23 8:17 PM:
---
{quote}
So, basically, the previous version was throwing exception if it was null OR
empty.
Now we throw if it is just null.
{quote}
Yep! That's what I am aiming for, which was the previous behavior I'd observed
in C* 4.0. Technically {{null}} could be allowed I suspect, but I figured for
consistency it should behave the same way (use an empty string for
{{keystore_password}} when there is no password, fail when null)
was (Author: andrew.tolbert):
{quote}
So, basically, the previous version was throwing exception if it was null OR
empty.
Now we throw if it is just null.
{quote}
Yep! That's what I am aiming for, which was the previous behavior I'd observed
in C* 4.0. Technically {{null}} could be allowed I suspect, but I figured for
consistency it should behave the same way (use an empty string for
{{keystore_password}} when there is no password)
> Empty keystore_password no longer allowed on encryption_options
> ---
>
> Key: CASSANDRA-18778
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18778
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 4.1.x, 5.0.x
>
>
> After CASSANDRA-18124 (introduced in 4.1.2 and 5.0) it is no longer possible
> to set an empty {{keystore_password}} under {{client_encryption_options}} or
> {{server_encryption_options}} using the default implementation
> {{{}DefaultSslContextFactory{}}}.
> While keytool does not allow generating keystores with empty passwords, it
> does support reading them. It is not uncommon to use PKCS12 certificates
> generated by other tools (eg. openssl) that do not enforce passwords.
> The fix for this should be pretty straightforward, which should involve
> changing
> [FileBasedSslContextFactory.validatePassword|https://github.com/apache/cassandra/blob/cassandra-4.1.2/src/java/org/apache/cassandra/security/FileBasedSslContextFactory.java#L128-L135]
> to only disallow null passwords (which would be consistent with previous
> versions). I will create pull requests against the relevant branches shortly.
> {noformat}
> Exception (org.apache.cassandra.exceptions.ConfigurationException)
> encountered during startup: Failed to initialize SSL
> org.apache.cassandra.exceptions.ConfigurationException: Failed to initialize
> SSL
> at
> org.apache.cassandra.config.DatabaseDescriptor.applySslContext(DatabaseDescriptor.java:1155)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applyAll(DatabaseDescriptor.java:390)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:204)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:188)
> at
> org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:804)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:747)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:875)
> Caused by: java.io.IOException: Failed to create SSL context using Native
> transport
> at
> org.apache.cassandra.security.SSLFactory.validateSslContext(SSLFactory.java:405)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applySslContext(DatabaseDescriptor.java:1150)
> ... 6 more
> Caused by: java.lang.IllegalArgumentException: 'keystore_password' must be
> specified
> at
> org.apache.cassandra.security.FileBasedSslContextFactory.validatePassword(FileBasedSslContextFactory.java:133)
> at
> org.apache.cassandra.security.FileBasedSslContextFactory.buildKeyManagerFactory(FileBasedSslContextFactory.java:151)
> at
> org.apache.cassandra.security.AbstractSslContextFactory.createNettySslContext(AbstractSslContextFactory.java:181)
> at
> org.apache.cassandra.security.SSLFactory.createNettySslContext(SSLFactory.java:168)
> at
> org.apache.cassandra.security.SSLFactory.validateSslContext(SSLFactory.java:355)
> ... 7 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18778) Empty keystore_password no longer allowed on encryption_options
[
https://issues.apache.org/jira/browse/CASSANDRA-18778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757650#comment-17757650
]
Stefan Miklosovic edited comment on CASSANDRA-18778 at 8/22/23 8:14 PM:
Honestly, I have a hard time to understand this ticket. In CASSANDRA-18124 we
made it possible to have nullable password. But here I see
{code}
if (password == null)
{
throw new IllegalArgumentException("'keystore_password' must be
specified");
}
{code}
That does not make sense to me. So the previous ticket was wrong?
EDIT
Ahaaa I get that ..
{code}
boolean keystorePasswordEmpty = StringUtils.isEmpty(password);
- if (keystorePasswordEmpty)
+ if (password == null)
{code}
{code}
public static boolean isEmpty(CharSequence cs) {
return cs == null || cs.length() == 0;
}
{code}
So, basically, the previous version was throwing exception if it was null OR
empty.
Now we throw if it is just null.
was (Author: smiklosovic):
Honestly, I have a hard time to understand this ticket. In (1) we made it
possible to have nullable password. But here I see
{code}
if (password == null)
{
throw new IllegalArgumentException("'keystore_password' must be
specified");
}
{code}
That does not make sense to me. So the previous ticket was wrong?
(1) https://issues.apache.org/jira/browse/CASSANDRA-18778
EDIT
Ahaaa I get that ..
{code}
boolean keystorePasswordEmpty = StringUtils.isEmpty(password);
- if (keystorePasswordEmpty)
+ if (password == null)
{code}
{code}
public static boolean isEmpty(CharSequence cs) {
return cs == null || cs.length() == 0;
}
{code}
So, basically, the previous version was throwing exception if it was null OR
empty.
Now we throw if it is just null.
> Empty keystore_password no longer allowed on encryption_options
> ---
>
> Key: CASSANDRA-18778
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18778
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 4.1.x, 5.0.x
>
>
> After CASSANDRA-18124 (introduced in 4.1.2 and 5.0) it is no longer possible
> to set an empty {{keystore_password}} under {{client_encryption_options}} or
> {{server_encryption_options}} using the default implementation
> {{{}DefaultSslContextFactory{}}}.
> While keytool does not allow generating keystores with empty passwords, it
> does support reading them. It is not uncommon to use PKCS12 certificates
> generated by other tools (eg. openssl) that do not enforce passwords.
> The fix for this should be pretty straightforward, which should involve
> changing
> [FileBasedSslContextFactory.validatePassword|https://github.com/apache/cassandra/blob/cassandra-4.1.2/src/java/org/apache/cassandra/security/FileBasedSslContextFactory.java#L128-L135]
> to only disallow null passwords (which would be consistent with previous
> versions). I will create pull requests against the relevant branches shortly.
> {noformat}
> Exception (org.apache.cassandra.exceptions.ConfigurationException)
> encountered during startup: Failed to initialize SSL
> org.apache.cassandra.exceptions.ConfigurationException: Failed to initialize
> SSL
> at
> org.apache.cassandra.config.DatabaseDescriptor.applySslContext(DatabaseDescriptor.java:1155)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applyAll(DatabaseDescriptor.java:390)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:204)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:188)
> at
> org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:804)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:747)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:875)
> Caused by: java.io.IOException: Failed to create SSL context using Native
> transport
> at
> org.apache.cassandra.security.SSLFactory.validateSslContext(SSLFactory.java:405)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applySslContext(DatabaseDescriptor.java:1150)
> ... 6 more
> Caused by: java.lang.IllegalArgumentException: 'keystore_password' must be
> specified
> at
> org.apache.cassandra.security.FileBasedSslContextFactory.validatePassword(FileBasedSslContextFactory.java:133)
> at
> org.apache.cassandra.security.FileBasedSslContextFactory.buildKeyManagerFactory(FileBasedSslContextFactory.java:151)
> at
> org.apache.cas
[jira] [Comment Edited] (CASSANDRA-18778) Empty keystore_password no longer allowed on encryption_options
[
https://issues.apache.org/jira/browse/CASSANDRA-18778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757650#comment-17757650
]
Stefan Miklosovic edited comment on CASSANDRA-18778 at 8/22/23 8:13 PM:
Honestly, I have a hard time to understand this ticket. In (1) we made it
possible to have nullable password. But here I see
{code}
if (password == null)
{
throw new IllegalArgumentException("'keystore_password' must be
specified");
}
{code}
That does not make sense to me. So the previous ticket was wrong?
(1) https://issues.apache.org/jira/browse/CASSANDRA-18778
EDIT
Ahaaa I get that ..
{code}
boolean keystorePasswordEmpty = StringUtils.isEmpty(password);
- if (keystorePasswordEmpty)
+ if (password == null)
{code}
{code}
public static boolean isEmpty(CharSequence cs) {
return cs == null || cs.length() == 0;
}
{code}
So, basically, the previous version was throwing exception if it was null OR
empty.
Now we throw if it is just null.
was (Author: smiklosovic):
Honestly, I have a hard time to understand this ticket. In (1) we made it
possible to have nullable password. But here I see
{code}
if (password == null)
{
throw new IllegalArgumentException("'keystore_password' must be
specified");
}
{code}
That does not make sense to me. So the previous ticket was wrong?
(1) https://issues.apache.org/jira/browse/CASSANDRA-18778
EDIT
Ahaaa I get that ..
{code}
boolean keystorePasswordEmpty = StringUtils.isEmpty(password);
- if (keystorePasswordEmpty)
+ if (password == null)
{code}
{code}
public static boolean isEmpty(CharSequence cs) {
return cs == null || cs.length() == 0;
}
{code}
So, basically, the previous version was throwing exception if it was null OR
empty.
Now we throw if it is just null.
> Empty keystore_password no longer allowed on encryption_options
> ---
>
> Key: CASSANDRA-18778
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18778
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 4.1.x, 5.0.x
>
>
> After CASSANDRA-18124 (introduced in 4.1.2 and 5.0) it is no longer possible
> to set an empty {{keystore_password}} under {{client_encryption_options}} or
> {{server_encryption_options}} using the default implementation
> {{{}DefaultSslContextFactory{}}}.
> While keytool does not allow generating keystores with empty passwords, it
> does support reading them. It is not uncommon to use PKCS12 certificates
> generated by other tools (eg. openssl) that do not enforce passwords.
> The fix for this should be pretty straightforward, which should involve
> changing
> [FileBasedSslContextFactory.validatePassword|https://github.com/apache/cassandra/blob/cassandra-4.1.2/src/java/org/apache/cassandra/security/FileBasedSslContextFactory.java#L128-L135]
> to only disallow null passwords (which would be consistent with previous
> versions). I will create pull requests against the relevant branches shortly.
> {noformat}
> Exception (org.apache.cassandra.exceptions.ConfigurationException)
> encountered during startup: Failed to initialize SSL
> org.apache.cassandra.exceptions.ConfigurationException: Failed to initialize
> SSL
> at
> org.apache.cassandra.config.DatabaseDescriptor.applySslContext(DatabaseDescriptor.java:1155)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applyAll(DatabaseDescriptor.java:390)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:204)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:188)
> at
> org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:804)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:747)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:875)
> Caused by: java.io.IOException: Failed to create SSL context using Native
> transport
> at
> org.apache.cassandra.security.SSLFactory.validateSslContext(SSLFactory.java:405)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applySslContext(DatabaseDescriptor.java:1150)
> ... 6 more
> Caused by: java.lang.IllegalArgumentException: 'keystore_password' must be
> specified
> at
> org.apache.cassandra.security.FileBasedSslContextFactory.validatePassword(FileBasedSslContextFactory.java:133)
> at
> org.apache.cassandra.security.FileBasedSslContextFactory.buildKeyManagerFactory(FileBasedSslContex
[jira] [Comment Edited] (CASSANDRA-18778) Empty keystore_password no longer allowed on encryption_options
[
https://issues.apache.org/jira/browse/CASSANDRA-18778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757650#comment-17757650
]
Stefan Miklosovic edited comment on CASSANDRA-18778 at 8/22/23 8:09 PM:
Honestly, I have a hard time to understand this ticket. In (1) we made it
possible to have nullable password. But here I see
{code}
if (password == null)
{
throw new IllegalArgumentException("'keystore_password' must be
specified");
}
{code}
That does not make sense to me. So the previous ticket was wrong?
(1) https://issues.apache.org/jira/browse/CASSANDRA-18778
EDIT
Ahaaa I get that ..
{code}
boolean keystorePasswordEmpty = StringUtils.isEmpty(password);
- if (keystorePasswordEmpty)
+ if (password == null)
{code}
{code}
public static boolean isEmpty(CharSequence cs) {
return cs == null || cs.length() == 0;
}
{code}
So, basically, the previous version was throwing exception if it was null OR
empty.
Now we throw if it is just null.
was (Author: smiklosovic):
Honestly, I have a hard time to understand this ticket. In (1) we made it
possible to have nullable password. But here I see
{code}
if (password == null)
{
throw new IllegalArgumentException("'keystore_password' must be
specified");
}
{code}
That does not make sense to me. So the previous ticket was wrong?
(1) https://issues.apache.org/jira/browse/CASSANDRA-18778
> Empty keystore_password no longer allowed on encryption_options
> ---
>
> Key: CASSANDRA-18778
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18778
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 4.1.x, 5.0.x
>
>
> After CASSANDRA-18124 (introduced in 4.1.2 and 5.0) it is no longer possible
> to set an empty {{keystore_password}} under {{client_encryption_options}} or
> {{server_encryption_options}} using the default implementation
> {{{}DefaultSslContextFactory{}}}.
> While keytool does not allow generating keystores with empty passwords, it
> does support reading them. It is not uncommon to use PKCS12 certificates
> generated by other tools (eg. openssl) that do not enforce passwords.
> The fix for this should be pretty straightforward, which should involve
> changing
> [FileBasedSslContextFactory.validatePassword|https://github.com/apache/cassandra/blob/cassandra-4.1.2/src/java/org/apache/cassandra/security/FileBasedSslContextFactory.java#L128-L135]
> to only disallow null passwords (which would be consistent with previous
> versions). I will create pull requests against the relevant branches shortly.
> {noformat}
> Exception (org.apache.cassandra.exceptions.ConfigurationException)
> encountered during startup: Failed to initialize SSL
> org.apache.cassandra.exceptions.ConfigurationException: Failed to initialize
> SSL
> at
> org.apache.cassandra.config.DatabaseDescriptor.applySslContext(DatabaseDescriptor.java:1155)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applyAll(DatabaseDescriptor.java:390)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:204)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:188)
> at
> org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:804)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:747)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:875)
> Caused by: java.io.IOException: Failed to create SSL context using Native
> transport
> at
> org.apache.cassandra.security.SSLFactory.validateSslContext(SSLFactory.java:405)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applySslContext(DatabaseDescriptor.java:1150)
> ... 6 more
> Caused by: java.lang.IllegalArgumentException: 'keystore_password' must be
> specified
> at
> org.apache.cassandra.security.FileBasedSslContextFactory.validatePassword(FileBasedSslContextFactory.java:133)
> at
> org.apache.cassandra.security.FileBasedSslContextFactory.buildKeyManagerFactory(FileBasedSslContextFactory.java:151)
> at
> org.apache.cassandra.security.AbstractSslContextFactory.createNettySslContext(AbstractSslContextFactory.java:181)
> at
> org.apache.cassandra.security.SSLFactory.createNettySslContext(SSLFactory.java:168)
> at
> org.apache.cassandra.security.SSLFactory.validateSslContext(SSLFactory.java:355)
> ... 7 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10
