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

Maulin Vasavada edited comment on CASSANDRA-18508 at 9/20/24 4:51 PM:
----------------------------------------------------------------------

Thanks [~smiklosovic] and [~jeetkundoug] . I think now beyond the local testing 
with a separate standalone example, I've below clarity for this ticket-
 * Client application does not have ability to specify SslClientSocketFactory. 
This means- in the current testing context for this ticket, I've to set system 
trust/key stores in the JMXEncryptionOptionsTests.
 * AND what you clarified about the port in the Client socket factory

Will make changes and update the branch I've. I've learned a lot so far (as 
usual :) ) working on this new thing.

One more clarification I seek is about two properties that seem to mean the 
same thing-
 # jmx.remote.rmi.client.socket.factory AND
 # com.sun.jndi.rmi.factory.socket

I am not able to find any documentation (honestly, I've not spend enough time 
yet) that explains the difference between them. Do we need both of them? If so 
in which use-case we need both of them vs one of them?  Is 1st one for the 
connection between client->JNDI-naming-service/rmiregistry AND 2nd one for the 
connection between client->JMX-server?


was (Author: maulin.vasavada):
Thanks [~smiklosovic] and [~jeetkundoug] . I think now beyond the local testing 
with a separate standalone example, I've below clarity for this ticket-
 * Client application does not have ability to specify SslClientSocketFactory. 
This means- in the current testing context for this ticket, I've to set system 
trust/key stores in the JMXEncryptionOptionsTests.
 * AND what you clarified about the port in the Client socket factory

Will make changes and update the branch I've. I've learned a lot so far (as 
usual :) ) working on this new thing.

> Sensitive JMX SSL configuration options can be easily exposed
> -------------------------------------------------------------
>
>                 Key: CASSANDRA-18508
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-18508
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Feature/Encryption, Local/Config
>            Reporter: Anthony Grasso
>            Assignee: Maulin Vasavada
>            Priority: Normal
>             Fix For: 5.x
>
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> We need a way to specify sensitive JMX SSL configuration options to avoid 
> them being easily exposed.
> When encrypting the JMX connection the passwords for the key and trust stores 
> must be specified using the {{javax.net.ssl.keyStorePassword}} and 
> {{javax.net.ssl.trustStorePassword}} options respectively in the 
> _cassandra-env.sh_ file. After Cassandra is started it is possible to see the 
> passwords by looking the running process ({{ps aux | grep "cassandra"}}).
> Java 8 has the ability to specify a configuration file that can contain these 
> security sensitive settings using the {{com.sun.management.config.file}} 
> argument. However, despite what the documentation 
> ([https://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html#gdevf])
>  says, both the {{com.sun.management.jmxremote}} and 
> {{com.sun.management.jmxremote.port}} arguments need to be defined in the 
> _cassandra-env.sh_ for the JVM to read the contents of the file.
> The problem with defining the {{com.sun.management.jmxremote.port}} argument 
> is it conflicts with the {{cassandra.jmx.remote.port}} argument. Even if the 
> port numbers are different, attempting an encrypted JMX connection using 
> {{nodetool}} fails and we see a {{ConnectException: 'Connection refused 
> (Connection refused)'}} error.
> One possible way to fix this is to introduce a new option that would allow a 
> file to be passed containing the JMX encryption options.



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