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

Maulin Vasavada commented on CASSANDRA-18778:
---------------------------------------------

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 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

Reply via email to