[
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 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: [email protected]
For additional commands, e-mail: [email protected]
