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

Maulin Vasavada commented on CASSANDRA-18508:
---------------------------------------------

[~drohrer] So before I could get to running 50 loops on ResourceLeakTest 
method, I was trying to see how to make the JMX client in IsolatedJmx.java and 
the JMXEncryptionOptionsTest.java (in my branch) use the custom key/trust 
store. However I realized that I am able to hit 127.0.0.1/jmxrmi initially fine 
with my custom Ssl client socket factory but eventually it tries to hit the 
Endpoint with serialized RMISslClientSocketFactoryImpl (equivalent of 
RMIClientSocketFactoryImpl in the distributed tests) which relies on the system 
properties for the key/trust stores. You can refer to the changes 
[here|[https://github.com/maulin-vasavada/cassandra/commit/d9513079decc5e6c6bee697824c5b384577772a9].]
 

I digged in to Java documentation etc on RMI and JMX RMI and it seems that 
Remote jmx client relies on the serialized client socket factory specified by 
the server side and if it wants to use a custom key/trust store it is a 
challenge. Do you have any suggestions?

> 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