[jira] [Commented] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17896158#comment-17896158
]
Maulin Vasavada commented on CASSANDRA-18508:
-
[~jeetkundoug] We are getting close now with Stefan's review almost done. Can
you please start taking a look?
Also, I wanted to close the loop on using `com.sun.jndi.rmi.factory.socket` in
the IsolatedJmxSocketFactory. I had to use it because without that it failed in
the IsolatedJmx while waiting for the client connector to connect to the JMX
server.
Thanks
> 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: 12h 40m
> 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
[jira] [Commented] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17893699#comment-17893699
]
Maulin Vasavada commented on CASSANDRA-18508:
-
Okay finally [~jeetkundoug] [~smiklosovic] I have raised the official PR -
[https://github.com/apache/cassandra/pull/3638] . Please review it and let me
know.
> 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: 0.5h
> 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
[jira] [Comment Edited] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17891731#comment-17891731
]
Maulin Vasavada edited comment on CASSANDRA-18508 at 10/22/24 5:46 PM:
---
[~jeetkundoug] So I see that two comments from you here.
# To clarify my question about client socket factories used for jmx connection
vs jndi lookup. I got that and I am going to remove setting jndi client socket
factory setting from IsolatedJmxSocketFactory.
# You mentioned moving DatabaseDescriptor.daemonInitialization() before
startJmx() in the Instance.java that should fix some issue. However, I am not
sure which issue you are referring to. Can you please elaborate? Are you
referring to my older question/observation that the dtests don't read from the
Cassandra yaml? If so, I'll give it a shot and see.
Beyond these two if there is no open question, I'll prepare a PR for the review
in this week.
was (Author: maulin.vasavada):
[~jeetkundoug] So I see that two comments from you here.
# To clarify my question about client socket factories used for jmx connection
vs jndi lookup. I got that and I am going to remove setting jndi client socket
factory setting from IsolatedJmxSocketFactory.
# You mentioned moving DatabaseDescriptor.daemonInitialization() before
startJmx() in the Instance.java that should fix some issue. However, I am not
sure which issue you are referring to. Can you please elaborate?
Beyond these two if there is no open question, I'll prepare a PR for the review
in this week.
> 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: 20m
> 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
[jira] [Commented] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17891731#comment-17891731
]
Maulin Vasavada commented on CASSANDRA-18508:
-
[~jeetkundoug] So I see that two comments from you here.
# To clarify my question about client socket factories used for jmx connection
vs jndi lookup. I got that and I am going to remove setting jndi client socket
factory setting from IsolatedJmxSocketFactory.
# You mentioned moving DatabaseDescriptor.daemonInitialization() before
startJmx() in the Instance.java that should fix some issue. However, I am not
sure which issue you are referring to. Can you please elaborate?
Beyond these two if there is no open question, I'll prepare a PR for the review
in this week.
> 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: 20m
> 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
[jira] [Commented] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17891082#comment-17891082
]
Maulin Vasavada commented on CASSANDRA-18508:
-
Okay [~jeetkundoug] I've good news. I build the latest trunk and re-applied
(cherry-picked) all my commits to a new branch and I can run the
ResourceLeakTest#looperJmxTest with numloop 50 count same as the trunk. I
created a new branch and here is [the temporary pull
request|https://github.com/maulin-vasavada/cassandra/pull/3] on myfork to show
the differences with the trunk
> 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: 20m
> 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
[jira] [Comment Edited] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17889875#comment-17889875
]
Maulin Vasavada edited comment on CASSANDRA-18508 at 10/15/24 11:58 PM:
So [~jeetkundoug] I could run the ResourceLeakTest#looperJMXTest from the trunk
now for 50 loop count. I prefer rebasing from the trunk for my branch and try
to run the same thing. Earlier it didnt' work from my branch for more than 27
loops without getting errors like below-
{noformat}
Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler
in thread "node2_isolatedExecutor:1"
Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler
in thread "node2_isolatedExecutor:2"
Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler
in thread "node2_isolatedExecutor:3"
WARN 23:07:31 Out of 1 commit log syncs over the past 0.00s with average
duration of 1938.39ms, 1 have exceeded the configured commit interval by an
average of 938.39ms
WARN [node1_COMMIT-LOG-WRITER] node1 2024-10-11 16:07:31,221
NoSpamLogger.java:107 - Out of 1 commit log syncs over the past 0.00s with
average duration of 1938.39ms, 1 have exceeded the configured commit interval
by an average of 938.39ms
Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler
in thread "node2_isolatedExecutor:8"Exception: java.lang.OutOfMemoryError
thrown from the UncaughtExceptionHandler in thread "node2_isolatedExecutor:6"
Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler
in thread "node2_isolatedExecutor:7"
Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler
in thread "node2_isolatedExecutor:4"
Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler
in thread "node2_isolatedExecutor:5"{noformat}
was (Author: maulin.vasavada):
So [~jeetkundoug] I could run the ResourceLeakTest#looperJMXTest from the trunk
now for 50 loop count. I prefer rebasing from the trunk for my branch and try
to run the same thing. Earlier it didnt' work from my branch for more than 27
loops without getting errors like below-
{noformat}
Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler
in thread "node2_isolatedExecutor:1"Exception: java.lang.OutOfMemoryError
thrown from the UncaughtExceptionHandler in thread
"node2_isolatedExecutor:2"Exception: java.lang.OutOfMemoryError thrown from the
UncaughtExceptionHandler in thread "node2_isolatedExecutor:3"
WARN 23:07:31 Out of 1 commit log syncs over the past 0.00s with average
duration of 1938.39ms, 1 have exceeded the configured commit interval by an
average of 938.39ms
WARN [node1_COMMIT-LOG-WRITER] node1 2024-10-11 16:07:31,221
NoSpamLogger.java:107 - Out of 1 commit log syncs over the past 0.00s with
average duration of 1938.39ms, 1 have exceeded the configured commit interval
by an average of 938.39msException: java.lang.OutOfMemoryError thrown from the
UncaughtExceptionHandler in thread "node2_isolatedExecutor:8"Exception:
java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread
"node2_isolatedExecutor:6"Exception: java.lang.OutOfMemoryError thrown from the
UncaughtExceptionHandler in thread "node2_isolatedExecutor:7"Exception:
java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread
"node2_isolatedExecutor:4"Exception: java.lang.OutOfMemoryError thrown from the
UncaughtExceptionHandler in thread "node2_isolatedExecutor:5"{noformat}
> 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.ht
[jira] [Comment Edited] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17889875#comment-17889875
]
Maulin Vasavada edited comment on CASSANDRA-18508 at 10/15/24 11:57 PM:
So [~jeetkundoug] I could run the ResourceLeakTest#looperJMXTest from the trunk
now for 50 loop count. I prefer rebasing from the trunk for my branch and try
to run the same thing. Earlier it didnt' work from my branch for more than 27
loops without getting errors like below-
{noformat}
Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler
in thread "node2_isolatedExecutor:1"Exception: java.lang.OutOfMemoryError
thrown from the UncaughtExceptionHandler in thread
"node2_isolatedExecutor:2"Exception: java.lang.OutOfMemoryError thrown from the
UncaughtExceptionHandler in thread "node2_isolatedExecutor:3"
WARN 23:07:31 Out of 1 commit log syncs over the past 0.00s with average
duration of 1938.39ms, 1 have exceeded the configured commit interval by an
average of 938.39ms
WARN [node1_COMMIT-LOG-WRITER] node1 2024-10-11 16:07:31,221
NoSpamLogger.java:107 - Out of 1 commit log syncs over the past 0.00s with
average duration of 1938.39ms, 1 have exceeded the configured commit interval
by an average of 938.39msException: java.lang.OutOfMemoryError thrown from the
UncaughtExceptionHandler in thread "node2_isolatedExecutor:8"Exception:
java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread
"node2_isolatedExecutor:6"Exception: java.lang.OutOfMemoryError thrown from the
UncaughtExceptionHandler in thread "node2_isolatedExecutor:7"Exception:
java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread
"node2_isolatedExecutor:4"Exception: java.lang.OutOfMemoryError thrown from the
UncaughtExceptionHandler in thread "node2_isolatedExecutor:5"{noformat}
was (Author: maulin.vasavada):
So [~jeetkundoug] I could run the ResourceLeakTest#looperJMXTest from the trunk
now for 50 loop count. I prefer rebasing from the trunk for my branch and try
to run the same thing. Earlier it didnt' work from my branch for more than 27
loops.
> 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
[jira] [Commented] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17889875#comment-17889875
]
Maulin Vasavada commented on CASSANDRA-18508:
-
So [~jeetkundoug] I could run the ResourceLeakTest#looperJMXTest from the trunk
now for 50 loop count. I prefer rebasing from the trunk for my branch and try
to run the same thing. Earlier it didnt' work from my branch for more than 27
loops.
> 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
[jira] [Commented] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17888007#comment-17888007
]
Maulin Vasavada commented on CASSANDRA-18508:
-
[~drohrer] ^^^ bump ^^^ When you get a chance, please take a look at the latest
comments here and the file changes and let me know your feedback. I still have
to run the {{ResourceLeakTest#looperJmxTest}} tests
> 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
[jira] [Commented] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17886569#comment-17886569
]
Maulin Vasavada commented on CASSANDRA-18508:
-
I've added Javadocs and refactored some class names now to reflect the purpose
better.
> 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
[jira] [Commented] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17885233#comment-17885233
]
Maulin Vasavada commented on CASSANDRA-18508:
-
Hi [~jeetkundoug] I've completed all the tests for JMX SSL - with
EncryptionOptions and with Systems SSL settings. At this point I think all the
functional/test requirements should be good. There are certain TODOs and
documentation work that I need to work on but otherwise this is mostly it. All
the changes are here for the review
[https://github.com/maulin-vasavada/cassandra/pull/2/files] . I would still
revisit all file naming conventions etc because there has been a lot of
refactoring to get to this stage and I need to take a pause and give a fresh
perspective to the changes. I still need to validate the
{{ResourceLeakTest#looperJmxTest locally but I should be able to get to it in
couple of days.}}
The only thing which is not clear to me still is - from the local tests why do
I've to set client SSL socket factory
[explicitly|https://github.com/maulin-vasavada/cassandra/pull/2/files#diff-da765e1bf3993569af1ee4e89f8201ea57adb2f7ccfcca7fa92a1907e7a88391R93]
? Will dig into it more but is it because everything is local in the same JVM
and because of that it doesn't serialize the client factory at all?
> 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
[jira] [Comment Edited] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
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
[jira] [Comment Edited] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
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:45 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.
Will make changes and update the branch I've. I've learned a lot so far (as
usual :) ) working on this new thing.
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.
Will make changes and update the branch I've. I think 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
[jira] [Comment Edited] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
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:45 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.
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.
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
[jira] [Commented] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17883347#comment-17883347
]
Maulin Vasavada commented on CASSANDRA-18508:
-
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.
Will make changes and update the branch I've. I think 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
[jira] [Commented] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17882836#comment-17882836
]
Maulin Vasavada commented on CASSANDRA-18508:
-
I fixed the local sample JMX app issue by using jmx service url specifying the
host in the url as well as customizing the Client Ssl socket factory to use
localhost instead of en0 host. Will play with it more before getting back to
this ticket's issue I ran into.
{noformat}
String jmxServiceURL =
"service:jmx:rmi://localhost:8999/jndi/rmi://localhost:/server";{noformat}
> 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
[jira] [Commented] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17882828#comment-17882828
]
Maulin Vasavada commented on CASSANDRA-18508:
-
Hi [~drohrer] and [~smiklosovic] I was testing a separate standalone JMX
client/server via
[this|https://docs.oracle.com/javase/1.5.0/docs/guide/jmx/tutorial/security.html#wp997044]
Java's documentation and get the `Connection refused` error in the Client code
for the Endpoint with the `en0` IPv4 address. So may be that is the first thing
I've to resolve before I can get to the Client side connection factory setting.
{noformat}
java.rmi.ConnectException: Connection refused to host: 10.0.0.14; nested
exception is:
java.net.ConnectException: Connection refused (Connection refused)
at
java.rmi/sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:623)
at
java.rmi/sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:209)
at
java.rmi/sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:196)
at java.rmi/sun.rmi.server.UnicastRef.invoke(UnicastRef.java:132)
at
java.management.rmi/javax.management.remote.rmi.RMIServerImpl_Stub.newClient(Unknown
Source)
at
java.management.rmi/javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java:2105)
at
java.management.rmi/javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:321)
at
java.management/javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:270)
at org.personal.security.simple.Client.main(Client.java:42)
Caused by: java.net.ConnectException: Connection refused (Connection refused)
at java.base/java.net.PlainSocketImpl.socketConnect(Native Method)
at
java.base/java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:412){noformat}
> 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
[jira] [Commented] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17881384#comment-17881384
]
Maulin Vasavada commented on CASSANDRA-18508:
-
While [~drohrer] can get a chance to look at this, I'll get back to running
ResourceLeak test for 50 loops.
> 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
[jira] [Comment Edited] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17881138#comment-17881138
]
Maulin Vasavada edited comment on CASSANDRA-18508 at 9/12/24 12:31 AM:
---
Okay, here is the issue I am running into. I've listed 3 EndPoints creating a
socket and the 2nd Endpoint in the below list is the one having the issue if I
DO NOT set javax.net.ssl.truststore at the System property level. This is
because for creating the client connection it is using serialized client socket
factory vs what I supplied (as you see in the 1st Endpoint). Below traces mean
that there are two calls (1 and 2) for creating new client socket from the
`waitForJmxAvailability()` (keep in mind that for testing I've put numAttempts
as 1 inside that method) - and 1st one works, 2nd one fails.
{noformat}
(1) EndPoint:
[127.0.0.1:7199,org.apache.cassandra.distributed.impl.IsolatedJmxTestClientSslSocketFactory@10574b01]
Call trace:
newSocket:613, TCPEndpoint (sun.rmi.transport.tcp)
createConnection:209, TCPChannel (sun.rmi.transport.tcp)
newConnection:196, TCPChannel (sun.rmi.transport.tcp)
newCall:343, UnicastRef (sun.rmi.server)
lookup:116, RegistryImpl_Stub (sun.rmi.registry)
lookup:133, RegistryContext (com.sun.jndi.rmi.registry)
lookup:220, GenericURLContext (com.sun.jndi.toolkit.url)
lookup:409, InitialContext (javax.naming)
findRMIServerJNDI:1839, RMIConnector (javax.management.remote.rmi)
findRMIServer:1813, RMIConnector (javax.management.remote.rmi)
connect:302, RMIConnector (javax.management.remote.rmi)
connect:270, JMXConnectorFactory (javax.management.remote)
getJmxConnector:94, JMXUtil (org.apache.cassandra.distributed.shared)
waitForJmxAvailability:201, IsolatedJmx (org.apache.cassandra.distributed.impl)
startJmx:142, IsolatedJmx (org.apache.cassandra.distributed.impl)
startJmx:651, Instance (org.apache.cassandra.distributed.impl)
partialStartup:711, Instance (org.apache.cassandra.distributed.impl)
lambda$startup$7:633, Instance (org.apache.cassandra.distributed.impl)
run:-1, 838800272 (org.apache.cassandra.distributed.impl.Instance$$Lambda$266)
call:124, FutureTask$2 (org.apache.cassandra.concurrent)
call:61, FutureTask (org.apache.cassandra.concurrent)
run:71, FutureTask (org.apache.cassandra.concurrent)
runWorker:1128, ThreadPoolExecutor (java.util.concurrent)
run:628, ThreadPoolExecutor$Worker (java.util.concurrent)
run:30, FastThreadLocalRunnable (io.netty.util.concurrent)
run:829, Thread (java.lang)
---
(2)EndPoint:
[10.0.0.14:7199,org.apache.cassandra.distributed.impl.RMISslClientSocketFactoryImpl@7f20]
Call trace:
newSocket:613, TCPEndpoint (sun.rmi.transport.tcp)
createConnection:209, TCPChannel (sun.rmi.transport.tcp)
newConnection:196, TCPChannel (sun.rmi.transport.tcp)
newCall:343, UnicastRef (sun.rmi.server)
dirty:104, DGCImpl_Stub (sun.rmi.transport)
makeDirtyCall:377, DGCClient$EndpointEntry (sun.rmi.transport)
registerRefs:319, DGCClient$EndpointEntry (sun.rmi.transport)
registerRefs:155, DGCClient (sun.rmi.transport)
registerRefs:102, ConnectionInputStream (sun.rmi.transport)
releaseInputStream:175, StreamRemoteCall (sun.rmi.transport)
done:340, StreamRemoteCall (sun.rmi.transport)
done:452, UnicastRef (sun.rmi.server)
lookup:132, RegistryImpl_Stub (sun.rmi.registry)
lookup:133, RegistryContext (com.sun.jndi.rmi.registry)
lookup:220, GenericURLContext (com.sun.jndi.toolkit.url)
lookup:409, InitialContext (javax.naming)
findRMIServerJNDI:1839, RMIConnector (javax.management.remote.rmi)
findRMIServer:1813, RMIConnector (javax.management.remote.rmi)
connect:302, RMIConnector (javax.management.remote.rmi)
connect:270, JMXConnectorFactory (javax.management.remote)
getJmxConnector:94, JMXUtil (org.apache.cassandra.distributed.shared)
waitForJmxAvailability:201, IsolatedJmx (org.apache.cassandra.distributed.impl)
startJmx:142, IsolatedJmx (org.apache.cassandra.distributed.impl)
startJmx:651, Instance (org.apache.cassandra.distributed.impl)
partialStartup:711, Instance (org.apache.cassandra.distributed.impl)
lambda$startup$7:633, Instance (org.apache.cassandra.distributed.impl)
run:-1, 874740624 (org.apache.cassandra.distributed.impl.Instance$$Lambda$266)
call:124, FutureTask$2 (org.apache.cassandra.concurrent)
call:61, FutureTask (org.apache.cassandra.concurrent)
run:71, FutureTask (org.apache.cassandra.concurrent)
runWorker:1128, ThreadPoolExecutor (java.util.concurrent)
run:628, ThreadPoolExecutor$Worker (java.util.concurrent)
run:30, FastThreadLocalRunnable (io.netty.util.concurrent)
run:829, Thread (java.lang)
--
(3) EndPoint:
[127.0.0.1:7199,org.apache.cassandra.distributed.impl.IsolatedJmxTestClientSslSocketFactory@2bc12da]
Call trace:
newSocket:613, TCPEndpoint (sun.rmi.transport.tcp)
createConnection:209, TCPChannel (sun.rmi.transport.tcp)
newConnection:196, TCPChannel (sun
[jira] [Comment Edited] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17881138#comment-17881138
]
Maulin Vasavada edited comment on CASSANDRA-18508 at 9/12/24 12:31 AM:
---
Okay, here is the issue I am running into. I've listed 3 EndPoints creating a
socket and the 2nd Endpoint in the below list is the one having the issue if I
DO NOT set javax.net.ssl.truststore at the System property level. This is
because for creating the client connection it is using serialized client socket
factory vs what I supplied (as you see in the 1st Endpoint). Below traces mean
that there are two calls for creating new client socket from the
`waitForJmxAvailability()` (keep in mind that for testing I've put numAttempts
as 1 inside that method)
{noformat}
(1) EndPoint:
[127.0.0.1:7199,org.apache.cassandra.distributed.impl.IsolatedJmxTestClientSslSocketFactory@10574b01]
Call trace:
newSocket:613, TCPEndpoint (sun.rmi.transport.tcp)
createConnection:209, TCPChannel (sun.rmi.transport.tcp)
newConnection:196, TCPChannel (sun.rmi.transport.tcp)
newCall:343, UnicastRef (sun.rmi.server)
lookup:116, RegistryImpl_Stub (sun.rmi.registry)
lookup:133, RegistryContext (com.sun.jndi.rmi.registry)
lookup:220, GenericURLContext (com.sun.jndi.toolkit.url)
lookup:409, InitialContext (javax.naming)
findRMIServerJNDI:1839, RMIConnector (javax.management.remote.rmi)
findRMIServer:1813, RMIConnector (javax.management.remote.rmi)
connect:302, RMIConnector (javax.management.remote.rmi)
connect:270, JMXConnectorFactory (javax.management.remote)
getJmxConnector:94, JMXUtil (org.apache.cassandra.distributed.shared)
waitForJmxAvailability:201, IsolatedJmx (org.apache.cassandra.distributed.impl)
startJmx:142, IsolatedJmx (org.apache.cassandra.distributed.impl)
startJmx:651, Instance (org.apache.cassandra.distributed.impl)
partialStartup:711, Instance (org.apache.cassandra.distributed.impl)
lambda$startup$7:633, Instance (org.apache.cassandra.distributed.impl)
run:-1, 838800272 (org.apache.cassandra.distributed.impl.Instance$$Lambda$266)
call:124, FutureTask$2 (org.apache.cassandra.concurrent)
call:61, FutureTask (org.apache.cassandra.concurrent)
run:71, FutureTask (org.apache.cassandra.concurrent)
runWorker:1128, ThreadPoolExecutor (java.util.concurrent)
run:628, ThreadPoolExecutor$Worker (java.util.concurrent)
run:30, FastThreadLocalRunnable (io.netty.util.concurrent)
run:829, Thread (java.lang)
---
(2)EndPoint:
[10.0.0.14:7199,org.apache.cassandra.distributed.impl.RMISslClientSocketFactoryImpl@7f20]
Call trace:
newSocket:613, TCPEndpoint (sun.rmi.transport.tcp)
createConnection:209, TCPChannel (sun.rmi.transport.tcp)
newConnection:196, TCPChannel (sun.rmi.transport.tcp)
newCall:343, UnicastRef (sun.rmi.server)
dirty:104, DGCImpl_Stub (sun.rmi.transport)
makeDirtyCall:377, DGCClient$EndpointEntry (sun.rmi.transport)
registerRefs:319, DGCClient$EndpointEntry (sun.rmi.transport)
registerRefs:155, DGCClient (sun.rmi.transport)
registerRefs:102, ConnectionInputStream (sun.rmi.transport)
releaseInputStream:175, StreamRemoteCall (sun.rmi.transport)
done:340, StreamRemoteCall (sun.rmi.transport)
done:452, UnicastRef (sun.rmi.server)
lookup:132, RegistryImpl_Stub (sun.rmi.registry)
lookup:133, RegistryContext (com.sun.jndi.rmi.registry)
lookup:220, GenericURLContext (com.sun.jndi.toolkit.url)
lookup:409, InitialContext (javax.naming)
findRMIServerJNDI:1839, RMIConnector (javax.management.remote.rmi)
findRMIServer:1813, RMIConnector (javax.management.remote.rmi)
connect:302, RMIConnector (javax.management.remote.rmi)
connect:270, JMXConnectorFactory (javax.management.remote)
getJmxConnector:94, JMXUtil (org.apache.cassandra.distributed.shared)
waitForJmxAvailability:201, IsolatedJmx (org.apache.cassandra.distributed.impl)
startJmx:142, IsolatedJmx (org.apache.cassandra.distributed.impl)
startJmx:651, Instance (org.apache.cassandra.distributed.impl)
partialStartup:711, Instance (org.apache.cassandra.distributed.impl)
lambda$startup$7:633, Instance (org.apache.cassandra.distributed.impl)
run:-1, 874740624 (org.apache.cassandra.distributed.impl.Instance$$Lambda$266)
call:124, FutureTask$2 (org.apache.cassandra.concurrent)
call:61, FutureTask (org.apache.cassandra.concurrent)
run:71, FutureTask (org.apache.cassandra.concurrent)
runWorker:1128, ThreadPoolExecutor (java.util.concurrent)
run:628, ThreadPoolExecutor$Worker (java.util.concurrent)
run:30, FastThreadLocalRunnable (io.netty.util.concurrent)
run:829, Thread (java.lang)
--
(3) EndPoint:
[127.0.0.1:7199,org.apache.cassandra.distributed.impl.IsolatedJmxTestClientSslSocketFactory@2bc12da]
Call trace:
newSocket:613, TCPEndpoint (sun.rmi.transport.tcp)
createConnection:209, TCPChannel (sun.rmi.transport.tcp)
newConnection:196, TCPChannel (sun.rmi.transport.tcp)
newCall:343, UnicastRef (s
[jira] [Commented] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17881138#comment-17881138
]
Maulin Vasavada commented on CASSANDRA-18508:
-
Okay, here is the issue I am running into. I've listed 3 EndPoints creating a
socket and the 2nd Endpoint in the below list is the one having the issue if I
DO NOT set javax.net.ssl.truststore at the System property level. This is
because for creating the client connection it is using serialized client socket
factory vs what I supplied (as you see in the 1st Endpoint).
{noformat}
(1) EndPoint:
[127.0.0.1:7199,org.apache.cassandra.distributed.impl.IsolatedJmxTestClientSslSocketFactory@10574b01]
Call trace:
newSocket:613, TCPEndpoint (sun.rmi.transport.tcp)
createConnection:209, TCPChannel (sun.rmi.transport.tcp)
newConnection:196, TCPChannel (sun.rmi.transport.tcp)
newCall:343, UnicastRef (sun.rmi.server)
lookup:116, RegistryImpl_Stub (sun.rmi.registry)
lookup:133, RegistryContext (com.sun.jndi.rmi.registry)
lookup:220, GenericURLContext (com.sun.jndi.toolkit.url)
lookup:409, InitialContext (javax.naming)
findRMIServerJNDI:1839, RMIConnector (javax.management.remote.rmi)
findRMIServer:1813, RMIConnector (javax.management.remote.rmi)
connect:302, RMIConnector (javax.management.remote.rmi)
connect:270, JMXConnectorFactory (javax.management.remote)
getJmxConnector:94, JMXUtil (org.apache.cassandra.distributed.shared)
waitForJmxAvailability:201, IsolatedJmx (org.apache.cassandra.distributed.impl)
startJmx:142, IsolatedJmx (org.apache.cassandra.distributed.impl)
startJmx:651, Instance (org.apache.cassandra.distributed.impl)
partialStartup:711, Instance (org.apache.cassandra.distributed.impl)
lambda$startup$7:633, Instance (org.apache.cassandra.distributed.impl)
run:-1, 838800272 (org.apache.cassandra.distributed.impl.Instance$$Lambda$266)
call:124, FutureTask$2 (org.apache.cassandra.concurrent)
call:61, FutureTask (org.apache.cassandra.concurrent)
run:71, FutureTask (org.apache.cassandra.concurrent)
runWorker:1128, ThreadPoolExecutor (java.util.concurrent)
run:628, ThreadPoolExecutor$Worker (java.util.concurrent)
run:30, FastThreadLocalRunnable (io.netty.util.concurrent)
run:829, Thread (java.lang)
---
(2)EndPoint:
[10.0.0.14:7199,org.apache.cassandra.distributed.impl.RMISslClientSocketFactoryImpl@7f20]
Call trace:
newSocket:613, TCPEndpoint (sun.rmi.transport.tcp)
createConnection:209, TCPChannel (sun.rmi.transport.tcp)
newConnection:196, TCPChannel (sun.rmi.transport.tcp)
newCall:343, UnicastRef (sun.rmi.server)
dirty:104, DGCImpl_Stub (sun.rmi.transport)
makeDirtyCall:377, DGCClient$EndpointEntry (sun.rmi.transport)
registerRefs:319, DGCClient$EndpointEntry (sun.rmi.transport)
registerRefs:155, DGCClient (sun.rmi.transport)
registerRefs:102, ConnectionInputStream (sun.rmi.transport)
releaseInputStream:175, StreamRemoteCall (sun.rmi.transport)
done:340, StreamRemoteCall (sun.rmi.transport)
done:452, UnicastRef (sun.rmi.server)
lookup:132, RegistryImpl_Stub (sun.rmi.registry)
lookup:133, RegistryContext (com.sun.jndi.rmi.registry)
lookup:220, GenericURLContext (com.sun.jndi.toolkit.url)
lookup:409, InitialContext (javax.naming)
findRMIServerJNDI:1839, RMIConnector (javax.management.remote.rmi)
findRMIServer:1813, RMIConnector (javax.management.remote.rmi)
connect:302, RMIConnector (javax.management.remote.rmi)
connect:270, JMXConnectorFactory (javax.management.remote)
getJmxConnector:94, JMXUtil (org.apache.cassandra.distributed.shared)
waitForJmxAvailability:201, IsolatedJmx (org.apache.cassandra.distributed.impl)
startJmx:142, IsolatedJmx (org.apache.cassandra.distributed.impl)
startJmx:651, Instance (org.apache.cassandra.distributed.impl)
partialStartup:711, Instance (org.apache.cassandra.distributed.impl)
lambda$startup$7:633, Instance (org.apache.cassandra.distributed.impl)
run:-1, 874740624 (org.apache.cassandra.distributed.impl.Instance$$Lambda$266)
call:124, FutureTask$2 (org.apache.cassandra.concurrent)
call:61, FutureTask (org.apache.cassandra.concurrent)
run:71, FutureTask (org.apache.cassandra.concurrent)
runWorker:1128, ThreadPoolExecutor (java.util.concurrent)
run:628, ThreadPoolExecutor$Worker (java.util.concurrent)
run:30, FastThreadLocalRunnable (io.netty.util.concurrent)
run:829, Thread (java.lang)
--
(3) EndPoint:
[127.0.0.1:7199,org.apache.cassandra.distributed.impl.IsolatedJmxTestClientSslSocketFactory@2bc12da]
Call trace:
newSocket:613, TCPEndpoint (sun.rmi.transport.tcp)
createConnection:209, TCPChannel (sun.rmi.transport.tcp)
newConnection:196, TCPChannel (sun.rmi.transport.tcp)
newCall:343, UnicastRef (sun.rmi.server)
lookup:116, RegistryImpl_Stub (sun.rmi.registry)
lookup:133, RegistryContext (com.sun.jndi.rmi.registry)
lookup:220, GenericURLContext (com.sun.jndi.toolkit.url)
lookup:409, InitialContext (javax.naming)
findRMIServerJNDI:1839
[jira] [Commented] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17881135#comment-17881135
]
Maulin Vasavada commented on CASSANDRA-18508:
-
Let me do some more debugging. I am not able to pin point the issue/use-case.
> 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
[jira] [Comment Edited] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1788#comment-1788
]
Maulin Vasavada edited comment on CASSANDRA-18508 at 9/11/24 7:41 PM:
--
[~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/d9513079decc5e6c6bee697824c5b38452a9]
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?
was (Author: maulin.vasavada):
[~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/d9513079decc5e6c6bee697824c5b38452a9].]
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
[jira] [Commented] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1788#comment-1788
]
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/d9513079decc5e6c6bee697824c5b38452a9].]
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
[jira] [Commented] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17877920#comment-17877920
]
Maulin Vasavada commented on CASSANDRA-18508:
-
Okay so it turns out that - I can run the {{ResourceLeakTest#looperJmxTest}}
locally after updating the {{numTestLoops}} variable to max 27 value
successfully. Beyond 27 it fails with OutOfMemory errors for the code from the
trunk and the CASSANDRA-18508-2 branch with my JMX changes. I am not sure if
that builds any confidence. Any suggestions welcome for local tuning that could
allow me run atleast 50 numTestLoops as Doug suggested.
> 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
[jira] [Commented] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17877583#comment-17877583
]
Maulin Vasavada commented on CASSANDRA-18508:
-
[~drohrer] It worked locally! Could run the below tests after the local subnet
settings you suggested. Now off to testing JMX tests.
{noformat}
cassandra-trunk %ant test-jvm-dtest-some
-Dtest.name=org.apache.cassandra.distributed.test.jmx.StorageServiceJmxTest{noformat}
> 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
[jira] [Comment Edited] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876880#comment-17876880
]
Maulin Vasavada edited comment on CASSANDRA-18508 at 8/27/24 2:13 AM:
--
Thanks Stefan and Doug. Will try your suggestions and verify. And yes I am on
Mac OS.
was (Author: maulin.vasavada):
Thanks Stefan and Doug. Will try your suggestions and verify.
> 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
[jira] [Commented] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876880#comment-17876880
]
Maulin Vasavada commented on CASSANDRA-18508:
-
Thanks Stefan and Doug. Will try your suggestions and verify.
> 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
[jira] [Commented] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876161#comment-17876161
]
Maulin Vasavada commented on CASSANDRA-18508:
-
Same exception running from the command line as well -
{noformat}
cassandra-trunk % ant test-jvm-dtest-some
-Dtest.name=org.apache.cassandra.distributed.test.jmx.StorageServiceJmxTest{noformat}
> 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
[jira] [Comment Edited] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876160#comment-17876160
]
Maulin Vasavada edited comment on CASSANDRA-18508 at 8/23/24 3:00 AM:
--
Okay, I see that I can't run dtest from the IDE. I'll follow
[https://cassandra.apache.org/_/development/testing.html#jvm_distributed_tests.|https://cassandra.apache.org/_/development/testing.html#jvm_distributed_tests]
Disclaimer: I have never run dtests locally before so its a learning for me.
However the documentation says I can run them from IDE but I keep getting into
below exception trying to run StorageServiceJmxTest in dtests so I guess I am
missing something. Any pointers [~drohrer] ?. Meanwhile I'll try command line
as per the documentation.
{noformat}
Caused by: java.rmi.server.ExportException: Port already in use: 7199; nested
exception is:
java.net.BindException: Can't assign requested address (Bind failed)
at java.rmi/sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:335)
at
java.rmi/sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:243)
at
java.rmi/sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:412)
at java.rmi/sun.rmi.transport.LiveRef.exportObject(LiveRef.java:147)
at
java.rmi/sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:234)
at java.rmi/sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:220)
at java.rmi/sun.rmi.registry.RegistryImpl.(RegistryImpl.java:180)
at java.rmi/sun.rmi.registry.RegistryImpl.(RegistryImpl.java:151)
at
org.apache.cassandra.utils.JMXServerUtils$JmxRegistry.(JMXServerUtils.java:342)
at
org.apache.cassandra.distributed.impl.IsolatedJmx.startJmx(IsolatedJmx.java:97)
... 10 more
Caused by: java.net.BindException: Can't assign requested address (Bind failed)
at java.base/java.net.PlainSocketImpl.socketBind(Native Method)
at
java.base/java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:452)
at java.base/java.net.ServerSocket.bind(ServerSocket.java:395)
at java.base/java.net.ServerSocket.(ServerSocket.java:257)
at
java.base/javax.net.DefaultServerSocketFactory.createServerSocket(ServerSocketFactory.java:231)
at
org.apache.cassandra.distributed.impl.CollectingRMIServerSocketFactoryImpl.createServerSocket(CollectingRMIServerSocketFactoryImpl.java:51)
at
java.rmi/sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:670)
at java.rmi/sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:324)
... 19 more
{noformat}
was (Author: maulin.vasavada):
Okay, I see that I can't run dtest from the IDE. I'll follow
[https://cassandra.apache.org/_/development/testing.html#jvm_distributed_tests.|https://cassandra.apache.org/_/development/testing.html#jvm_distributed_tests]
However the documentation says I can run them from IDE but I keep getting into
below exception trying to run StorageServiceJmxTest in dtests so I guess I am
missing something. Any pointers [~drohrer] ?. Meanwhile I'll try command line
as per the documentation.
{noformat}
Caused by: java.rmi.server.ExportException: Port already in use: 7199; nested
exception is:
java.net.BindException: Can't assign requested address (Bind failed)
at java.rmi/sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:335)
at
java.rmi/sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:243)
at
java.rmi/sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:412)
at java.rmi/sun.rmi.transport.LiveRef.exportObject(LiveRef.java:147)
at
java.rmi/sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:234)
at java.rmi/sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:220)
at java.rmi/sun.rmi.registry.RegistryImpl.(RegistryImpl.java:180)
at java.rmi/sun.rmi.registry.RegistryImpl.(RegistryImpl.java:151)
at
org.apache.cassandra.utils.JMXServerUtils$JmxRegistry.(JMXServerUtils.java:342)
at
org.apache.cassandra.distributed.impl.IsolatedJmx.startJmx(IsolatedJmx.java:97)
... 10 more
Caused by: java.net.BindException: Can't assign requested address (Bind failed)
at java.base/java.net.PlainSocketImpl.socketBind(Native Method)
at
java.base/java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:452)
at java.base/java.net.ServerSocket.bind(ServerSocket.java:395)
at java.base/java.net.ServerSocket.(ServerSocket.java:257)
at
java.base/javax.net.DefaultServerSocketFactory.createServerSocket(ServerSocketFactory.java:231)
at
org.apache.cassandra.distributed.impl.CollectingRMIServerSocketFactoryImpl.createServerSocket(CollectingRMIServerSocketFactoryImpl.java:51)
at
java.rmi/sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:670)
at java.rmi/sun.rmi.transport.tcp.TCPTransport.listen(TCP
[jira] [Comment Edited] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876160#comment-17876160
]
Maulin Vasavada edited comment on CASSANDRA-18508 at 8/23/24 2:58 AM:
--
Okay, I see that I can't run dtest from the IDE. I'll follow
[https://cassandra.apache.org/_/development/testing.html#jvm_distributed_tests.|https://cassandra.apache.org/_/development/testing.html#jvm_distributed_tests]
However the documentation says I can run them from IDE but I keep getting into
below exception trying to run StorageServiceJmxTest in dtests so I guess I am
missing something. Any pointers [~drohrer] ?. Meanwhile I'll try command line
as per the documentation.
{noformat}
Caused by: java.rmi.server.ExportException: Port already in use: 7199; nested
exception is:
java.net.BindException: Can't assign requested address (Bind failed)
at java.rmi/sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:335)
at
java.rmi/sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:243)
at
java.rmi/sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:412)
at java.rmi/sun.rmi.transport.LiveRef.exportObject(LiveRef.java:147)
at
java.rmi/sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:234)
at java.rmi/sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:220)
at java.rmi/sun.rmi.registry.RegistryImpl.(RegistryImpl.java:180)
at java.rmi/sun.rmi.registry.RegistryImpl.(RegistryImpl.java:151)
at
org.apache.cassandra.utils.JMXServerUtils$JmxRegistry.(JMXServerUtils.java:342)
at
org.apache.cassandra.distributed.impl.IsolatedJmx.startJmx(IsolatedJmx.java:97)
... 10 more
Caused by: java.net.BindException: Can't assign requested address (Bind failed)
at java.base/java.net.PlainSocketImpl.socketBind(Native Method)
at
java.base/java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:452)
at java.base/java.net.ServerSocket.bind(ServerSocket.java:395)
at java.base/java.net.ServerSocket.(ServerSocket.java:257)
at
java.base/javax.net.DefaultServerSocketFactory.createServerSocket(ServerSocketFactory.java:231)
at
org.apache.cassandra.distributed.impl.CollectingRMIServerSocketFactoryImpl.createServerSocket(CollectingRMIServerSocketFactoryImpl.java:51)
at
java.rmi/sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:670)
at java.rmi/sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:324)
... 19 more
{noformat}
was (Author: maulin.vasavada):
Okay, I see that I can't run dtest from the IDE. I'll follow
[https://cassandra.apache.org/_/development/testing.html#jvm_distributed_tests.|https://cassandra.apache.org/_/development/testing.html#jvm_distributed_tests]
However the documentation says I can run them from IDE but I keep getting into
below exception so I guess I am missing something. Any pointers [~drohrer] ?.
Meanwhile I'll try command line as per the documentation.
{noformat}
Caused by: java.rmi.server.ExportException: Port already in use: 7199; nested
exception is:
java.net.BindException: Can't assign requested address (Bind failed)
at java.rmi/sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:335)
at
java.rmi/sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:243)
at
java.rmi/sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:412)
at java.rmi/sun.rmi.transport.LiveRef.exportObject(LiveRef.java:147)
at
java.rmi/sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:234)
at java.rmi/sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:220)
at java.rmi/sun.rmi.registry.RegistryImpl.(RegistryImpl.java:180)
at java.rmi/sun.rmi.registry.RegistryImpl.(RegistryImpl.java:151)
at
org.apache.cassandra.utils.JMXServerUtils$JmxRegistry.(JMXServerUtils.java:342)
at
org.apache.cassandra.distributed.impl.IsolatedJmx.startJmx(IsolatedJmx.java:97)
... 10 more
Caused by: java.net.BindException: Can't assign requested address (Bind failed)
at java.base/java.net.PlainSocketImpl.socketBind(Native Method)
at
java.base/java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:452)
at java.base/java.net.ServerSocket.bind(ServerSocket.java:395)
at java.base/java.net.ServerSocket.(ServerSocket.java:257)
at
java.base/javax.net.DefaultServerSocketFactory.createServerSocket(ServerSocketFactory.java:231)
at
org.apache.cassandra.distributed.impl.CollectingRMIServerSocketFactoryImpl.createServerSocket(CollectingRMIServerSocketFactoryImpl.java:51)
at
java.rmi/sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:670)
at java.rmi/sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:324)
... 19 more
{noformat}
> Sensitive JMX SSL configuration options can be easily exposed
> ---
[jira] [Comment Edited] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876160#comment-17876160
]
Maulin Vasavada edited comment on CASSANDRA-18508 at 8/23/24 2:57 AM:
--
Okay, I see that I can't run dtest from the IDE. I'll follow
[https://cassandra.apache.org/_/development/testing.html#jvm_distributed_tests.|https://cassandra.apache.org/_/development/testing.html#jvm_distributed_tests]
However the documentation says I can run them from IDE but I keep getting into
below exception so I guess I am missing something. Meanwhile I'll try command
line as per the documentation.
{noformat}
Caused by: java.rmi.server.ExportException: Port already in use: 7199; nested
exception is:
java.net.BindException: Can't assign requested address (Bind failed)
at java.rmi/sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:335)
at
java.rmi/sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:243)
at
java.rmi/sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:412)
at java.rmi/sun.rmi.transport.LiveRef.exportObject(LiveRef.java:147)
at
java.rmi/sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:234)
at java.rmi/sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:220)
at java.rmi/sun.rmi.registry.RegistryImpl.(RegistryImpl.java:180)
at java.rmi/sun.rmi.registry.RegistryImpl.(RegistryImpl.java:151)
at
org.apache.cassandra.utils.JMXServerUtils$JmxRegistry.(JMXServerUtils.java:342)
at
org.apache.cassandra.distributed.impl.IsolatedJmx.startJmx(IsolatedJmx.java:97)
... 10 more
Caused by: java.net.BindException: Can't assign requested address (Bind failed)
at java.base/java.net.PlainSocketImpl.socketBind(Native Method)
at
java.base/java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:452)
at java.base/java.net.ServerSocket.bind(ServerSocket.java:395)
at java.base/java.net.ServerSocket.(ServerSocket.java:257)
at
java.base/javax.net.DefaultServerSocketFactory.createServerSocket(ServerSocketFactory.java:231)
at
org.apache.cassandra.distributed.impl.CollectingRMIServerSocketFactoryImpl.createServerSocket(CollectingRMIServerSocketFactoryImpl.java:51)
at
java.rmi/sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:670)
at java.rmi/sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:324)
... 19 more
{noformat}
was (Author: maulin.vasavada):
Okay, I realized that I can't run dtest from the IDE. I'll follow
[https://cassandra.apache.org/_/development/testing.html#jvm_distributed_tests]
> 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: commi
[jira] [Comment Edited] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876160#comment-17876160
]
Maulin Vasavada edited comment on CASSANDRA-18508 at 8/23/24 2:57 AM:
--
Okay, I see that I can't run dtest from the IDE. I'll follow
[https://cassandra.apache.org/_/development/testing.html#jvm_distributed_tests.|https://cassandra.apache.org/_/development/testing.html#jvm_distributed_tests]
However the documentation says I can run them from IDE but I keep getting into
below exception so I guess I am missing something. Any pointers [~drohrer] ?.
Meanwhile I'll try command line as per the documentation.
{noformat}
Caused by: java.rmi.server.ExportException: Port already in use: 7199; nested
exception is:
java.net.BindException: Can't assign requested address (Bind failed)
at java.rmi/sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:335)
at
java.rmi/sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:243)
at
java.rmi/sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:412)
at java.rmi/sun.rmi.transport.LiveRef.exportObject(LiveRef.java:147)
at
java.rmi/sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:234)
at java.rmi/sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:220)
at java.rmi/sun.rmi.registry.RegistryImpl.(RegistryImpl.java:180)
at java.rmi/sun.rmi.registry.RegistryImpl.(RegistryImpl.java:151)
at
org.apache.cassandra.utils.JMXServerUtils$JmxRegistry.(JMXServerUtils.java:342)
at
org.apache.cassandra.distributed.impl.IsolatedJmx.startJmx(IsolatedJmx.java:97)
... 10 more
Caused by: java.net.BindException: Can't assign requested address (Bind failed)
at java.base/java.net.PlainSocketImpl.socketBind(Native Method)
at
java.base/java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:452)
at java.base/java.net.ServerSocket.bind(ServerSocket.java:395)
at java.base/java.net.ServerSocket.(ServerSocket.java:257)
at
java.base/javax.net.DefaultServerSocketFactory.createServerSocket(ServerSocketFactory.java:231)
at
org.apache.cassandra.distributed.impl.CollectingRMIServerSocketFactoryImpl.createServerSocket(CollectingRMIServerSocketFactoryImpl.java:51)
at
java.rmi/sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:670)
at java.rmi/sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:324)
... 19 more
{noformat}
was (Author: maulin.vasavada):
Okay, I see that I can't run dtest from the IDE. I'll follow
[https://cassandra.apache.org/_/development/testing.html#jvm_distributed_tests.|https://cassandra.apache.org/_/development/testing.html#jvm_distributed_tests]
However the documentation says I can run them from IDE but I keep getting into
below exception so I guess I am missing something. Meanwhile I'll try command
line as per the documentation.
{noformat}
Caused by: java.rmi.server.ExportException: Port already in use: 7199; nested
exception is:
java.net.BindException: Can't assign requested address (Bind failed)
at java.rmi/sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:335)
at
java.rmi/sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:243)
at
java.rmi/sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:412)
at java.rmi/sun.rmi.transport.LiveRef.exportObject(LiveRef.java:147)
at
java.rmi/sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:234)
at java.rmi/sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:220)
at java.rmi/sun.rmi.registry.RegistryImpl.(RegistryImpl.java:180)
at java.rmi/sun.rmi.registry.RegistryImpl.(RegistryImpl.java:151)
at
org.apache.cassandra.utils.JMXServerUtils$JmxRegistry.(JMXServerUtils.java:342)
at
org.apache.cassandra.distributed.impl.IsolatedJmx.startJmx(IsolatedJmx.java:97)
... 10 more
Caused by: java.net.BindException: Can't assign requested address (Bind failed)
at java.base/java.net.PlainSocketImpl.socketBind(Native Method)
at
java.base/java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:452)
at java.base/java.net.ServerSocket.bind(ServerSocket.java:395)
at java.base/java.net.ServerSocket.(ServerSocket.java:257)
at
java.base/javax.net.DefaultServerSocketFactory.createServerSocket(ServerSocketFactory.java:231)
at
org.apache.cassandra.distributed.impl.CollectingRMIServerSocketFactoryImpl.createServerSocket(CollectingRMIServerSocketFactoryImpl.java:51)
at
java.rmi/sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:670)
at java.rmi/sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:324)
... 19 more
{noformat}
> Sensitive JMX SSL configuration options can be easily exposed
> -
>
> Key
[jira] [Commented] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876160#comment-17876160
]
Maulin Vasavada commented on CASSANDRA-18508:
-
Okay, I realized that I can't run dtest from the IDE. I'll follow
[https://cassandra.apache.org/_/development/testing.html#jvm_distributed_tests]
> 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
[jira] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[ https://issues.apache.org/jira/browse/CASSANDRA-18508 ]
Maulin Vasavada deleted comment on CASSANDRA-18508:
-
was (Author: maulin.vasavada):
Okay so its not branch specific. I can't run the same JMX tests (example:
StorageServiceJmxTest) from the trunk also in my local IDE. I've not run the
dtest locally before can you please point me to a guide for it? I keep getting
below exception -
{noformat}
Caused by: java.rmi.server.ExportException: Port already in use: 7199; nested
exception is:
java.net.BindException: Can't assign requested address (Bind failed)
at java.rmi/sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:335)
at
java.rmi/sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:243)
at
java.rmi/sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:412)
at java.rmi/sun.rmi.transport.LiveRef.exportObject(LiveRef.java:147)
at
java.rmi/sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:234)
at java.rmi/sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:220)
at java.rmi/sun.rmi.registry.RegistryImpl.(RegistryImpl.java:180)
at java.rmi/sun.rmi.registry.RegistryImpl.(RegistryImpl.java:151)
at
org.apache.cassandra.utils.JMXServerUtils$JmxRegistry.(JMXServerUtils.java:342)
at
org.apache.cassandra.distributed.impl.IsolatedJmx.startJmx(IsolatedJmx.java:97)
... 10 more
Caused by: java.net.BindException: Can't assign requested address (Bind failed)
at java.base/java.net.PlainSocketImpl.socketBind(Native Method)
at
java.base/java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:452)
at java.base/java.net.ServerSocket.bind(ServerSocket.java:395)
at java.base/java.net.ServerSocket.(ServerSocket.java:257)
at
java.base/javax.net.DefaultServerSocketFactory.createServerSocket(ServerSocketFactory.java:231)
at
org.apache.cassandra.distributed.impl.CollectingRMIServerSocketFactoryImpl.createServerSocket(CollectingRMIServerSocketFactoryImpl.java:51)
at
java.rmi/sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:670)
at java.rmi/sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:324)
... 19 more{noformat}
> 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
[jira] [Commented] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876159#comment-17876159
]
Maulin Vasavada commented on CASSANDRA-18508:
-
Okay so its not branch specific. I can't run the same JMX tests (example:
StorageServiceJmxTest) from the trunk also in my local IDE. I've not run the
dtest locally before can you please point me to a guide for it? I keep getting
below exception -
{noformat}
Caused by: java.rmi.server.ExportException: Port already in use: 7199; nested
exception is:
java.net.BindException: Can't assign requested address (Bind failed)
at java.rmi/sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:335)
at
java.rmi/sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:243)
at
java.rmi/sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:412)
at java.rmi/sun.rmi.transport.LiveRef.exportObject(LiveRef.java:147)
at
java.rmi/sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:234)
at java.rmi/sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:220)
at java.rmi/sun.rmi.registry.RegistryImpl.(RegistryImpl.java:180)
at java.rmi/sun.rmi.registry.RegistryImpl.(RegistryImpl.java:151)
at
org.apache.cassandra.utils.JMXServerUtils$JmxRegistry.(JMXServerUtils.java:342)
at
org.apache.cassandra.distributed.impl.IsolatedJmx.startJmx(IsolatedJmx.java:97)
... 10 more
Caused by: java.net.BindException: Can't assign requested address (Bind failed)
at java.base/java.net.PlainSocketImpl.socketBind(Native Method)
at
java.base/java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:452)
at java.base/java.net.ServerSocket.bind(ServerSocket.java:395)
at java.base/java.net.ServerSocket.(ServerSocket.java:257)
at
java.base/javax.net.DefaultServerSocketFactory.createServerSocket(ServerSocketFactory.java:231)
at
org.apache.cassandra.distributed.impl.CollectingRMIServerSocketFactoryImpl.createServerSocket(CollectingRMIServerSocketFactoryImpl.java:51)
at
java.rmi/sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:670)
at java.rmi/sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:324)
... 19 more{noformat}
> 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
[jira] [Comment Edited] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17875749#comment-17875749
]
Maulin Vasavada edited comment on CASSANDRA-18508 at 8/22/24 7:16 PM:
--
Ha ha! Now all other JMX feature tests fail except the one I made work :) I'm
starting to see the challenge making E2E tests with SSL work. Let me spend
sometime to figure out if I can come up with a solution. I created a [draft
PR|https://github.com/maulin-vasavada/cassandra/pull/2/files] on my fork to
compare changes made for the SSL support in IsolatedJMX (in case we decide to
drop the E2E testability plan due to its complexity). [~drohrer] you can check
[JMXEncryptionOptionsTest#testDefaultSettings()|https://github.com/maulin-vasavada/cassandra/blob/CASSANDRA-18508-2/test/distributed/org/apache/cassandra/distributed/test/JMXEncryptionOptionsTest.java#L65].
However forgive my small hacks for now (like setting system property for
truststore etc).
Edited: I added the draft PR link in this post
was (Author: maulin.vasavada):
Ha ha! Now all other JMX feature tests fail except the one I made work :) I'm
starting to see the challenge making E2E tests with SSL work. Let me spend
sometime to figure out if I can come up with a solution. I created [another
branch|https://github.com/maulin-vasavada/cassandra/tree/CASSANDRA-18508-2] for
the SSL support in IsolatedJMX (in case we decide to drop the E2E testability
plan due to its complexity). [~drohrer] you can check
[JMXEncryptionOptionsTest#testDefaultSettings()|https://github.com/maulin-vasavada/cassandra/blob/CASSANDRA-18508-2/test/distributed/org/apache/cassandra/distributed/test/JMXEncryptionOptionsTest.java#L65].
However forgive my small hacks for now (like setting system property for
truststore etc).
> 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
[jira] [Comment Edited] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17875749#comment-17875749
]
Maulin Vasavada edited comment on CASSANDRA-18508 at 8/22/24 7:08 PM:
--
Ha ha! Now all other JMX feature tests fail except the one I made work :) I'm
starting to see the challenge making E2E tests with SSL work. Let me spend
sometime to figure out if I can come up with a solution. I created [another
branch|https://github.com/maulin-vasavada/cassandra/tree/CASSANDRA-18508-2] for
the SSL support in IsolatedJMX (in case we decide to drop the E2E testability
plan due to its complexity). [~drohrer] you can check
[JMXEncryptionOptionsTest#testDefaultSettings()|https://github.com/maulin-vasavada/cassandra/blob/CASSANDRA-18508-2/test/distributed/org/apache/cassandra/distributed/test/JMXEncryptionOptionsTest.java#L65].
However forgive my small hacks for now (like setting system property for
truststore etc).
was (Author: maulin.vasavada):
Ha ha! Now all other JMX feature tests fail except the one I made work :) I'm
starting to see the challenge making E2E tests with SSL work. Let me spend
sometime to figure out if I can come up with a solution. I created [another
branch|https://github.com/maulin-vasavada/cassandra/tree/CASSANDRA-18508-2] for
the SSL support in IsolatedJMX (in case we decide to drop the E2E testability
plan due to its complexity). [~drohrer] you can check
[JMXEncryptionOptionsTest|https://github.com/maulin-vasavada/cassandra/blob/CASSANDRA-18508-2/test/distributed/org/apache/cassandra/distributed/test/JMXEncryptionOptionsTest.java].
However forgive my small hacks for now (like setting system property for
truststore etc).
> 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
[jira] [Comment Edited] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17875749#comment-17875749
]
Maulin Vasavada edited comment on CASSANDRA-18508 at 8/22/24 6:25 AM:
--
Ha ha! Now all other JMX feature tests fail except the one I made work :) I'm
starting to see the challenge making E2E tests with SSL work. Let me spend
sometime to figure out if I can come up with a solution. I created [another
branch|https://github.com/maulin-vasavada/cassandra/tree/CASSANDRA-18508-2] for
the SSL support in IsolatedJMX (in case we decide to drop the E2E testability
plan due to its complexity). [~drohrer] you can check
[JMXEncryptionOptionsTest|https://github.com/maulin-vasavada/cassandra/blob/CASSANDRA-18508-2/test/distributed/org/apache/cassandra/distributed/test/JMXEncryptionOptionsTest.java].
However forgive my small hacks for now (like setting system property for
truststore etc).
was (Author: maulin.vasavada):
Ha ha! Now all other JMX feature tests fail except the one I made work :) I'm
starting to see the challenge making E2E tests with SSL work. Let me spend
sometime to figure out if I can come up with a solution. I created [another
branch|https://github.com/maulin-vasavada/cassandra/tree/CASSANDRA-18508-2] for
the SSL support in IsolatedJMX (in case we decide to drop the E2E testability
plan due to its complexity). [~drohrer] you can check
[JMXEncryptionOptionsTest|https://github.com/maulin-vasavada/cassandra/blob/CASSANDRA-18508-2/test/distributed/org/apache/cassandra/distributed/test/JMXEncryptionOptionsTest.java].
However forgive me small hacks for now (like setting system property for
truststore etc).
> 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
[jira] [Comment Edited] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17875749#comment-17875749
]
Maulin Vasavada edited comment on CASSANDRA-18508 at 8/22/24 6:24 AM:
--
Ha ha! Now all other JMX feature tests fail except the one I made work :) I'm
starting to see the challenge making E2E tests with SSL work. Let me spend
sometime to figure out if I can come up with a solution. I created [another
branch|https://github.com/maulin-vasavada/cassandra/tree/CASSANDRA-18508-2] for
the SSL support in IsolatedJMX (in case we decide to drop the E2E testability
plan due to its complexity). [~drohrer] you can check
[JMXEncryptionOptionsTest|https://github.com/maulin-vasavada/cassandra/blob/CASSANDRA-18508-2/test/distributed/org/apache/cassandra/distributed/test/JMXEncryptionOptionsTest.java].
However forgive me small hacks for now (like setting system property for
truststore etc).
was (Author: maulin.vasavada):
Ha ha! Now all other JMX feature tests fail except the one I made work :) I'm
starting to see the challenge making E2E tests with SSL work. Let me spend
sometime to figure out if I can come up with a solution. I created [another
branch|https://github.com/maulin-vasavada/cassandra/tree/CASSANDRA-18508-2]
before I started on the changes for IsolatedJMX. [~drohrer] you can check
[JMXEncryptionOptionsTest|https://github.com/maulin-vasavada/cassandra/blob/CASSANDRA-18508-2/test/distributed/org/apache/cassandra/distributed/test/JMXEncryptionOptionsTest.java].
However forgive me small hacks for now (like setting system property for
truststore etc).
> 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
[jira] [Commented] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17875749#comment-17875749
]
Maulin Vasavada commented on CASSANDRA-18508:
-
Ha ha! Now all other JMX feature tests fail except the one I made work :) I'm
starting to see the challenge making E2E tests with SSL work. Let me spend
sometime to figure out if I can come up with a solution. I created [another
branch|https://github.com/maulin-vasavada/cassandra/tree/CASSANDRA-18508-2]
before I started on the changes for IsolatedJMX. [~drohrer] you can check
[JMXEncryptionOptionsTest|https://github.com/maulin-vasavada/cassandra/blob/CASSANDRA-18508-2/test/distributed/org/apache/cassandra/distributed/test/JMXEncryptionOptionsTest.java].
However forgive me small hacks for now (like setting system property for
truststore etc).
> 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
[jira] [Commented] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17875301#comment-17875301
]
Maulin Vasavada commented on CASSANDRA-18508:
-
Sure [~drohrer] Still working on making the e2e test work. Almost there. Will
check the test you suggested and any e2e tests that has Feature.JMX enabled.
However, I'll need a thorough review from experts like you on these changes.
Looks quite bit of changes.
> 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
[jira] [Commented] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17874034#comment-17874034
]
Maulin Vasavada commented on CASSANDRA-18508:
-
Thanks [~drohrer] I'll take a look at your suggestion. I was thinking about
that possibility already. Also I feel we have a scope to reduce duplication of
code between IsolatedJmx and JMXServerUtils. Will take a holistic look. Thank
you.
> 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
[jira] [Commented] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17873387#comment-17873387
]
Maulin Vasavada commented on CASSANDRA-18508:
-
[~smiklosovic] While trying to enable client auth for JMX in the tests, I
debugged and realized that the current tests using in-memory cluster config use
IsolatedJmx which doesn't support SSL at all. Hence I realized that in the
JMXEncryptionOptionsTest I created, it is not using the jmx_encryption_options
at all. Only the JMX server started by JMXServerUtils uses the
jmx_encryption_options. Now I've to figure out how to make sure that we can
write tests that uses JMXServerUtils and not IsolatedJmx OR modify IsolatedJmx
to support SSL. Looking for your opinion on the testing path.
> 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
[jira] [Commented] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17872772#comment-17872772
]
Maulin Vasavada commented on CASSANDRA-18508:
-
So far I added _JMXEncryptionOptionsTest_ in the PR with JKS and PEM format
keystore/truststore material. Now will look into adding test cases with
client_auth true.
> 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
[jira] [Commented] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17872524#comment-17872524
]
Maulin Vasavada commented on CASSANDRA-18508:
-
I am able to use the similar logic and carry the same test as in the
JMXGetterCheckTest. Will work on it to add more tests.
> 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
[jira] [Commented] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17872523#comment-17872523
]
Maulin Vasavada commented on CASSANDRA-18508:
-
Makes sense! I feel I should be able to use that.
> 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
[jira] [Commented] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17872489#comment-17872489
]
Maulin Vasavada commented on CASSANDRA-18508:
-
[~smiklosovic] [~brandon.williams] while I am trying to get distributed in-jvm
test work to start JMX server with EncryptionOptions, can you please review the
PR and let me know any feedback?
Below are the details about the issue I am facing making distributed in-jvm
test work for JMX-
I tried to build a simple test based on the existing
[JMXGetterCheckTest|[https://github.com/apache/cassandra/blob/trunk/test/distributed/org/apache/cassandra/distributed/test/jmx/JMXGetterCheckTest.java].]
I also looked at the GuardrailPasswordTest and find that there is similarity
with JMXGetterCheckTest. I am trying a simplified copy of the
JMXGetterCheckTest with just one Cluster instead of the forloop it has. However
I am running into below exception when I try to set EncryptionOptions in the
ClusterConfig.
{code:java}
public void testGetters() throws Exception
{
EncryptionOptions jmxEncryptionOptions = new EncryptionOptions();
try (Cluster cluster = Cluster.build(1).withConfig(c -> c.with(Feature.JMX)
.set("jmx_encryption_options", jmxEncryptionOptions)).start())
{
testAllValidGetters(cluster);
}
}
org.yaml.snakeyaml.error.YAMLException: Unable to find getter for property
'enabled' on object
org.apache.cassandra.config.EncryptionOptions@abed783c:java.lang.reflect.InvocationTargetException
at
org.yaml.snakeyaml.introspector.MethodProperty.get(MethodProperty.java:81)
at
org.yaml.snakeyaml.representer.Representer.representJavaBean(Representer.java:97)
at
org.yaml.snakeyaml.representer.Representer$RepresentJavaBean.representData(Representer.java:73)
at
org.yaml.snakeyaml.representer.BaseRepresenter.representData(BaseRepresenter.java:122)
at
org.yaml.snakeyaml.representer.BaseRepresenter.representMapping(BaseRepresenter.java:174)
at
org.yaml.snakeyaml.representer.SafeRepresenter$RepresentMap.representData(SafeRepresenter.java:330)
at
org.yaml.snakeyaml.representer.BaseRepresenter.representData(BaseRepresenter.java:111)
at
org.yaml.snakeyaml.representer.BaseRepresenter.represent(BaseRepresenter.java:81)
at org.yaml.snakeyaml.Yaml.represent(Yaml.java:242)
at
org.apache.cassandra.config.YamlConfigurationLoader.fromMap(YamlConfigurationLoader.java:226)
at
org.apache.cassandra.distributed.impl.Instance.loadConfig(Instance.java:874)
{code}
Basically I realize that may be all the dtests use in-memory ClusterConfig vs
loading it from cassandra.yaml. However I didn't find any reference that uses
EncryptionOptions in the ClusterConfig the way I am trying to use. I also tried
to set DTEST_API_CONFIG_CHECK as false but it seems it creates that key in the
'dtest' map and the code in the
[Instance.loadConfig()|https://github.com/apache/cassandra/blob/trunk/test/distributed/org/apache/cassandra/distributed/impl/Instance.java#L872]
is not able to skip the check.
{noformat}
Constants.KEY_DTEST_API_CONFIG_CHECK
if (overrides.get(Constants.KEY_DTEST_API_CONFIG_CHECK) != null)
check = (boolean)
overrides.get(Constants.KEY_DTEST_API_CONFIG_CHECK);{noformat}
> 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 t
[jira] [Commented] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17871819#comment-17871819
]
Maulin Vasavada commented on CASSANDRA-18508:
-
Thanks, will check.
> 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
[jira] [Comment Edited] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17870626#comment-17870626
]
Maulin Vasavada edited comment on CASSANDRA-18508 at 8/2/24 9:03 PM:
-
[~smiklosovic] [~brandon.williams] [~anthony] opened the
[PR-3457|https://github.com/apache/cassandra/pull/3457] for the review. Stefan
I sincerely hope this time I could overcome the spacing issues I faced in the
past :) I did run `ant check` locally so hoping for the best. I added more unit
tests for JMX SSL verification (for existing and the PR changes) but didn't
find any tests I can use to really validate Remote JMX SSL config working at
runtime by creating server-socket etc. Open to suggestions on how to add that
kind of test.
This PR should also address
https://issues.apache.org/jira/browse/CASSANDRA-11695
was (Author: maulin.vasavada):
[~smiklosovic] [~brandon.williams] [~anthony] opened the
[PR-3457|https://github.com/apache/cassandra/pull/3457] for the review. Stefan
I sincerely hope this time I could overcome the spacing issues I faced in the
past :) I did run `ant check` locally so hoping for the best. I added more unit
tests for JMX SSL verification (for existing and the PR changes) but didn't
find any tests I can use to really validate Remote JMX SSL config working at
runtime by creating server-socket etc. Open to suggestions on how to add that
kind of test.
> 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
[jira] [Comment Edited] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17870626#comment-17870626
]
Maulin Vasavada edited comment on CASSANDRA-18508 at 8/2/24 9:01 PM:
-
[~smiklosovic] [~brandon.williams] [~anthony] opened the
[PR-3457|https://github.com/apache/cassandra/pull/3457] for the review. Stefan
I sincerely hope this time I could overcome the spacing issues I faced in the
past :) I did run `ant check` locally so hoping for the best. I added more unit
tests for JMX SSL verification (for existing and the PR changes) but didn't
find any tests I can use to really validate Remote JMX SSL config working at
runtime by creating server-socket etc. Open to suggestions on how to add that
kind of test.
was (Author: maulin.vasavada):
[~smiklosovic] [~brandon.williams] [~anthony] opened the
[PR-3457|https://github.com/apache/cassandra/pull/3457] for the review. Stefan
I sincerely hope this time I could over the spacing issues :) I did run `ant
check` locally so hoping for the best. I added more unit tests for JMX SSL
verification (for existing and the PR changes) but didn't find any tests I can
use to really validate Remote JMX SSL config working at runtime by creating
server-socket etc. Open to suggestions on how to add that kind of test.
> 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
[jira] [Commented] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17870626#comment-17870626
]
Maulin Vasavada commented on CASSANDRA-18508:
-
[~smiklosovic] [~brandon.williams] [~anthony] opened the
[PR-3457|https://github.com/apache/cassandra/pull/3457] for the review. Stefan
I sincerely hope this time I could over the spacing issues :) I did run `ant
check` locally so hoping for the best. I added more unit tests for JMX SSL
verification (for existing and the PR changes) but didn't find any tests I can
use to really validate Remote JMX SSL config working at runtime by creating
server-socket etc. Open to suggestions on how to add that kind of test.
> 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
[jira] [Commented] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17869748#comment-17869748
]
Maulin Vasavada commented on CASSANDRA-18508:
-
Thanks Stefan. Will do! Hot reloading of the ssl config changes seems little
bit more involved and challenging for JMX since everything is statically
created/registered. However we can get to discuss that once other changes look
good.
> 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
>
>
> 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
[jira] [Commented] (CASSANDRA-13428) Security: provide keystore_password_file and truststore_password_file options
[
https://issues.apache.org/jira/browse/CASSANDRA-13428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17869082#comment-17869082
]
Maulin Vasavada commented on CASSANDRA-13428:
-
Since my first stab at the changes focuses on JMX SSL pluggable config, I have
updated that ticket correspondingly with a link to my changes. Once that gets
going in a direction, I'll add support for the file paths for the passwords in
the encryption options.
> Security: provide keystore_password_file and truststore_password_file options
> -
>
> Key: CASSANDRA-13428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13428
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption, Local/Config
>Reporter: Bas van Dijk
>Assignee: Maulin Vasavada
>Priority: Normal
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> Currently passwords are stored in plaintext in the configuration file as in:
> {code}
> server_encryption_options:
> keystore_password: secret
> truststore_password: secret
> client_encryption_options:
> keystore_password: secret
> {code}
> This has the disadvantage that, in order to protect the secrets, the whole
> configuration file needs to have restricted ownership and permissions. This
> is problematic in operating systems like NixOS where configuration files are
> usually stored in world-readable locations.
> A secure option would be to store secrets in files (with restricted ownership
> and permissions) and reference those files from the unrestricted
> configuration file as in for example:
> {code}
> server_encryption_options:
> keystore_password_file: /run/keys/keystore-password
> truststore_password_file: /run/keys/truststore-password
> client_encryption_options:
> keystore_password_file: /run/keys/keystore-password
> {code}
> This is trivial to implement and provides a big gain in security.
> So in summary I'm proposing to add the {{keystore_password_file}} and
> {{truststore_password_file}} options besides the existing
> {{keystore_password}} and {{truststore_password options}}. The former will
> take precedence over the latter.
--
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] [Commented] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17869080#comment-17869080
]
Maulin Vasavada commented on CASSANDRA-18508:
-
[~brandon.williams] [~smiklosovic] I've taken a stab at this. Please review
[this|https://github.com/maulin-vasavada/cassandra/pull/1/files#diff-0437b960b37ef273e346b1e6e1b451336102a2cb7e8b4d4fc6b90c64e21dbe40]
(not a PR yet). I still have to add Hot reloading of the JMX SSL Context but
overall I could use the existing encryption_options for making JMX SSL config
also pluggable.
> 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
>
>
> 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
[jira] [Commented] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17868985#comment-17868985
]
Maulin Vasavada commented on CASSANDRA-18508:
-
I have made code changes but it seems there are not tests for the JMX SSL
functionality. I will add some to validate the changes.
> 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
>
>
> 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
[jira] [Assigned] (CASSANDRA-18508) Sensitive JMX SSL configuration options can be easily exposed
[
https://issues.apache.org/jira/browse/CASSANDRA-18508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maulin Vasavada reassigned CASSANDRA-18508:
---
Assignee: Maulin Vasavada (was: Stefan Miklosovic)
> 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
>
>
> 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
[jira] [Comment Edited] (CASSANDRA-13428) Security: provide keystore_password_file and truststore_password_file options
[
https://issues.apache.org/jira/browse/CASSANDRA-13428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17867181#comment-17867181
]
Maulin Vasavada edited comment on CASSANDRA-13428 at 7/19/24 6:12 AM:
--
After re-looking at the patch for
[CASSANDRA-18508|https://github.com/apache/cassandra/pull/2338/files#diff-9582994c492faf525011dc9af77fb3c06f48d78d4e04666538a36bb019af8f1d]
and my above thinking, I am exactly sure what needs to be done. What I
mentioned above should work.
was (Author: maulin.vasavada):
After re-looking at the patch for CASSANDRA-18508 and my above thinking, I am
exactly sure what needs to be done. What I mentioned above should work.
> Security: provide keystore_password_file and truststore_password_file options
> -
>
> Key: CASSANDRA-13428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13428
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption, Local/Config
>Reporter: Bas van Dijk
>Assignee: Maulin Vasavada
>Priority: Normal
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> Currently passwords are stored in plaintext in the configuration file as in:
> {code}
> server_encryption_options:
> keystore_password: secret
> truststore_password: secret
> client_encryption_options:
> keystore_password: secret
> {code}
> This has the disadvantage that, in order to protect the secrets, the whole
> configuration file needs to have restricted ownership and permissions. This
> is problematic in operating systems like NixOS where configuration files are
> usually stored in world-readable locations.
> A secure option would be to store secrets in files (with restricted ownership
> and permissions) and reference those files from the unrestricted
> configuration file as in for example:
> {code}
> server_encryption_options:
> keystore_password_file: /run/keys/keystore-password
> truststore_password_file: /run/keys/truststore-password
> client_encryption_options:
> keystore_password_file: /run/keys/keystore-password
> {code}
> This is trivial to implement and provides a big gain in security.
> So in summary I'm proposing to add the {{keystore_password_file}} and
> {{truststore_password_file}} options besides the existing
> {{keystore_password}} and {{truststore_password options}}. The former will
> take precedence over the latter.
--
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] [Commented] (CASSANDRA-13428) Security: provide keystore_password_file and truststore_password_file options
[
https://issues.apache.org/jira/browse/CASSANDRA-13428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17867181#comment-17867181
]
Maulin Vasavada commented on CASSANDRA-13428:
-
After re-looking at the patch for CASSANDRA-18508 and my above thinking, I am
exactly sure what needs to be done. What I mentioned above should work.
> Security: provide keystore_password_file and truststore_password_file options
> -
>
> Key: CASSANDRA-13428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13428
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption, Local/Config
>Reporter: Bas van Dijk
>Assignee: Maulin Vasavada
>Priority: Normal
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> Currently passwords are stored in plaintext in the configuration file as in:
> {code}
> server_encryption_options:
> keystore_password: secret
> truststore_password: secret
> client_encryption_options:
> keystore_password: secret
> {code}
> This has the disadvantage that, in order to protect the secrets, the whole
> configuration file needs to have restricted ownership and permissions. This
> is problematic in operating systems like NixOS where configuration files are
> usually stored in world-readable locations.
> A secure option would be to store secrets in files (with restricted ownership
> and permissions) and reference those files from the unrestricted
> configuration file as in for example:
> {code}
> server_encryption_options:
> keystore_password_file: /run/keys/keystore-password
> truststore_password_file: /run/keys/truststore-password
> client_encryption_options:
> keystore_password_file: /run/keys/keystore-password
> {code}
> This is trivial to implement and provides a big gain in security.
> So in summary I'm proposing to add the {{keystore_password_file}} and
> {{truststore_password_file}} options besides the existing
> {{keystore_password}} and {{truststore_password options}}. The former will
> take precedence over the latter.
--
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-13428) Security: provide keystore_password_file and truststore_password_file options
[
https://issues.apache.org/jira/browse/CASSANDRA-13428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17867136#comment-17867136
]
Maulin Vasavada edited comment on CASSANDRA-13428 at 7/18/24 11:47 PM:
---
So since there is already a `ssl_context_factory` config which allows to plug
any mechanism to load the TLS credentials from, just to allow File paths for
passwords would be easy by adding an implementation for `ISslContextFactory`
e.g. In
[FileBasedSslContextFactory|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/FileBasedSslContextFactory.java#L276]
we can modify the FileBasedSslContext to add file path for the password .
However, the JMX is using the [Java's
SocketFactory|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/utils/JMXServerUtils.java#L98]
which is currently reading TLS credentials from the system properties even
with the Patch provided in CASSANDRA-18508.
The current internal class hierarchy can be found on the Cassandra's [Security
documentation|https://cassandra.apache.org/doc/stable/cassandra/operating/security.html#tlsssl-encryption].
My conclusion is that- we can make two changes-
# Modify existing FileBasedSslContextFactory to support file paths for the
password (with additional configuration options like keystore_password_file and
truststore_password_file suggested in this ticket's title) AND
# Modify the JMX server utils to use SSLContext and implement
JMXSslContextFactory implementation that can allow any format like existing
implementations of the ISslContextFactory (like PEM based etc) without creating
class-bloat (too many new classes).
## And add `jmx_encryption_options` configuration in the cassandra yaml as
discussed on the other ticket's thread. This configuration will default to use
DefaultJMXSslContextFactory implementation that exactly supports defaults of
client/server encryption options configuration.
[~smiklosovic] [~brandon.williams] please let me know your thoughts. May be
[~djoshi] 's thought also would be helpful given his/his-teams' work on this
area.
I will try to put this thing together as code to have better clarity (and help
me self-realize if there are any challenges doing it this way :) )
was (Author: maulin.vasavada):
So since there is already a `ssl_context_factory` config which allows to plug
any mechanism to load the TLS credentials from, just to allow File paths for
passwords would be easy by adding an implementation for `ISslContextFactory`
e.g. In
[FileBasedSslContextFactory|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/FileBasedSslContextFactory.java#L276]
we can modify the FileBasedSslContext to add file path for the password .
However, the JMX is using the [Java's
SocketFactory|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/utils/JMXServerUtils.java#L98]
which is currently reading TLS credentials from the system properties even
with the Patch provided in CASSANDRA-18508.
The current internal class hierarchy can be found on the Cassandra's [Security
documentation|https://cassandra.apache.org/doc/stable/cassandra/operating/security.html#tlsssl-encryption].
My conclusion is that- we can make two changes-
# Modify existing FileBasedSslContextFactory to support file paths for the
password (with additional configuration options like keystore_password_file and
truststore_password_file suggested in this ticket's title) AND
# Modify the JMX server utils to use SSLContext and implement
JMXSslContextFactory implementation that can allow any format like existing
implementations of the ISslContextFactory (like PEM based etc) without creating
class-bloat (too many new classes).
## And add `jmx_encryption_options` configuration in the cassandra yaml as
discussed on the other ticket's thread. This configuration will default to use
DefaultJMXSslContextFactory implementation that exactly supports defaults of
client/server encryption options configuration.
[~smiklosovic] [~brandon.williams] please let me know your thoughts. May be
[~djoshi] 's thought also would be helpful given his/his-teams' work on this
area.
> Security: provide keystore_password_file and truststore_password_file options
> -
>
> Key: CASSANDRA-13428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13428
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption, Local/Config
>Reporter: Bas van Dijk
>Assignee: Maulin Vasavada
>Priority: Normal
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> Currently passwords are stored in plaintext in the configuration file as in:
> {code}
>
[jira] [Comment Edited] (CASSANDRA-13428) Security: provide keystore_password_file and truststore_password_file options
[
https://issues.apache.org/jira/browse/CASSANDRA-13428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17867136#comment-17867136
]
Maulin Vasavada edited comment on CASSANDRA-13428 at 7/18/24 11:46 PM:
---
So since there is already a `ssl_context_factory` config which allows to plug
any mechanism to load the TLS credentials from, just to allow File paths for
passwords would be easy by adding an implementation for `ISslContextFactory`
e.g. In
[FileBasedSslContextFactory|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/FileBasedSslContextFactory.java#L276]
we can modify the FileBasedSslContext to add file path for the password .
However, the JMX is using the [Java's
SocketFactory|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/utils/JMXServerUtils.java#L98]
which is currently reading TLS credentials from the system properties even
with the Patch provided in CASSANDRA-18508.
The current internal class hierarchy can be found on the Cassandra's [Security
documentation|https://cassandra.apache.org/doc/stable/cassandra/operating/security.html#tlsssl-encryption].
My conclusion is that- we can make two changes-
# Modify existing FileBasedSslContextFactory to support file paths for the
password (with additional configuration options like keystore_password_file and
truststore_password_file suggested in this ticket's title) AND
# Modify the JMX server utils to use SSLContext and implement
JMXSslContextFactory implementation that can allow any format like existing
implementations of the ISslContextFactory (like PEM based etc) without creating
class-bloat (too many new classes).
## And add `jmx_encryption_options` configuration in the cassandra yaml as
discussed on the other ticket's thread. This configuration will default to use
DefaultJMXSslContextFactory implementation that exactly supports defaults of
client/server encryption options configuration.
[~smiklosovic] [~brandon.williams] please let me know your thoughts. May be
[~djoshi] 's thought also would be helpful given his/his-teams' work on this
area.
was (Author: maulin.vasavada):
So since there is already a `ssl_context_factory` config which allows to plug
any mechanism to load the TLS credentials from, just to allow File paths for
passwords would be easy by adding an implementation for `ISslContextFactory`
e.g. In
[FileBasedSslContextFactory|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/FileBasedSslContextFactory.java#L276]
we can modify the FileBasedSslContext to add file path for the password .
However, the JMX is using the [Java's
SocketFactory|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/utils/JMXServerUtils.java#L98]
which is currently reading TLS credentials from the system properties even
with the Patch provided in CASSANDRA-18508.
The current internal class hierarchy can be found on the Cassandra's [Security
documentation|https://cassandra.apache.org/doc/stable/cassandra/operating/security.html#tlsssl-encryption].
My conclusion is that- we can make two changes-
# Modify existing FileBasedSslContextFactory to support file paths for the
password (with additional configuration options like keystore_password_file and
truststore_password_file suggested in this ticket's title) AND
# Modify the JMX server utils to use SSLContext and implement
JMXSslContextFactory implementation that can allow any format like existing
implementations of the ISslContextFactory (like PEM based etc) without creating
class-bloat (too many new classes).
## And add `jmx_encryption_options` configuration in the cassandra yaml as
discussed on the other ticket's thread.
[~smiklosovic] [~brandon.williams] please let me know your thoughts. May be
[~djoshi] 's thought also would be helpful given his/his-teams' work on this
area.
> Security: provide keystore_password_file and truststore_password_file options
> -
>
> Key: CASSANDRA-13428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13428
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption, Local/Config
>Reporter: Bas van Dijk
>Assignee: Maulin Vasavada
>Priority: Normal
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> Currently passwords are stored in plaintext in the configuration file as in:
> {code}
> server_encryption_options:
> keystore_password: secret
> truststore_password: secret
> client_encryption_options:
> keystore_password: secret
> {code}
> This has the disadvantage that, in order to protect the secrets, the whole
> configuration file needs to have restricted ownership and
[jira] [Comment Edited] (CASSANDRA-13428) Security: provide keystore_password_file and truststore_password_file options
[
https://issues.apache.org/jira/browse/CASSANDRA-13428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17867136#comment-17867136
]
Maulin Vasavada edited comment on CASSANDRA-13428 at 7/18/24 11:45 PM:
---
So since there is already a `ssl_context_factory` config which allows to plug
any mechanism to load the TLS credentials from, just to allow File paths for
passwords would be easy by adding an implementation for `ISslContextFactory`
e.g. In
[FileBasedSslContextFactory|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/FileBasedSslContextFactory.java#L276]
we can modify the FileBasedSslContext to add file path for the password .
However, the JMX is using the [Java's
SocketFactory|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/utils/JMXServerUtils.java#L98]
which is currently reading TLS credentials from the system properties even
with the Patch provided in CASSANDRA-18508.
The current internal class hierarchy can be found on the Cassandra's [Security
documentation|https://cassandra.apache.org/doc/stable/cassandra/operating/security.html#tlsssl-encryption].
My conclusion is that- we can make two changes-
# Modify existing FileBasedSslContextFactory to support file paths for the
password (with additional configuration options like keystore_password_file and
truststore_password_file suggested in this ticket's title) AND
# Modify the JMX server utils to use SSLContext and implement
JMXSslContextFactory implementation that can allow any format like existing
implementations of the ISslContextFactory (like PEM based etc) without creating
class-bloat (too many new classes).
## And add `jmx_encryption_options` configuration in the cassandra yaml as
discussed on the other ticket's thread.
[~smiklosovic] [~brandon.williams] please let me know your thoughts. May be
[~djoshi] 's thought also would be helpful given his/his-teams' work on this
area.
was (Author: maulin.vasavada):
So since there is already a `ssl_context_factory` config which allows to plug
any mechanism to load the TLS credentials from, just to allow File paths for
passwords would be easy by adding an implementation for `ISslContextFactory`
e.g. In
[FileBasedSslContextFactory|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/FileBasedSslContextFactory.java#L276]
we can modify the FileBasedSslContext to add file path for the password .
However, the JMX is using the [Java's
SocketFactory|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/utils/JMXServerUtils.java#L98]
which is currently reading TLS credentials from the system properties even
with the Patch provided in CASSANDRA-18508.
The current internal class hierarchy can be found on the Cassandra's [Security
documentation|https://cassandra.apache.org/doc/stable/cassandra/operating/security.html#tlsssl-encryption].
My conclusion is that- we can make two changes-
# Modify existing FileBasedSslContextFactory to support file paths for the
password (with additional configuration options like keystore_password_file and
truststore_password_file suggested in this ticket's title) AND
# Modify the JMX server utils to use SSLContext and implement
JMXSslContextFactory implementation that can allow any format like existing
implementations of the ISslContextFactory (like PEM based etc) without creating
class-bloat (too many new classes).
[~smiklosovic] [~brandon.williams] please let me know your thoughts. May be
[~djoshi] 's thought also would be helpful given his/his-teams' work on this
area.
> Security: provide keystore_password_file and truststore_password_file options
> -
>
> Key: CASSANDRA-13428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13428
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption, Local/Config
>Reporter: Bas van Dijk
>Assignee: Maulin Vasavada
>Priority: Normal
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> Currently passwords are stored in plaintext in the configuration file as in:
> {code}
> server_encryption_options:
> keystore_password: secret
> truststore_password: secret
> client_encryption_options:
> keystore_password: secret
> {code}
> This has the disadvantage that, in order to protect the secrets, the whole
> configuration file needs to have restricted ownership and permissions. This
> is problematic in operating systems like NixOS where configuration files are
> usually stored in world-readable locations.
> A secure option would be to store secrets in files (with restricted ownership
> and permissions) and reference those files from the unr
[jira] [Comment Edited] (CASSANDRA-13428) Security: provide keystore_password_file and truststore_password_file options
[
https://issues.apache.org/jira/browse/CASSANDRA-13428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17867136#comment-17867136
]
Maulin Vasavada edited comment on CASSANDRA-13428 at 7/18/24 11:42 PM:
---
So since there is already a `ssl_context_factory` config which allows to plug
any mechanism to load the TLS credentials from, just to allow File paths for
passwords would be easy by adding an implementation for `ISslContextFactory`
e.g. In
[FileBasedSslContextFactory|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/FileBasedSslContextFactory.java#L276]
we can modify the FileBasedSslContext to add file path for the password .
However, the JMX is using the [Java's
SocketFactory|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/utils/JMXServerUtils.java#L98]
which is currently reading TLS credentials from the system properties even
with the Patch provided in CASSANDRA-18508.
The current internal class hierarchy can be found on the Cassandra's [Security
documentation|https://cassandra.apache.org/doc/stable/cassandra/operating/security.html#tlsssl-encryption].
My conclusion is that- we can make two changes-
# Modify existing FileBasedSslContextFactory to support file paths for the
password (with additional configuration options like keystore_password_file and
truststore_password_file suggested in this ticket's title) AND
# Modify the JMX server utils to use SSLContext and implement
JMXSslContextFactory implementation that can allow any format like existing
implementations of the ISslContextFactory (like PEM based etc) without creating
class-bloat (too many new classes).
[~smiklosovic] [~brandon.williams] please let me know your thoughts. May be
[~djoshi] 's thought also would be helpful given his/his-teams' work on this
area.
was (Author: maulin.vasavada):
So since there is already a `ssl_context_factory` config which allows to plug
any mechanism to load the TLS credentials from, just to allow File paths for
passwords would be easy by adding an implementation for `ISslContextFactory`
e.g. In
[FileBasedSslContextFactory|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/FileBasedSslContextFactory.java#L276]
we can modify the FileBasedSslContext to add file path for the password .
However, the JMX is using the [Java's
SocketFactory|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/utils/JMXServerUtils.java#L98]
which is currently reading TLS credentials from the system properties even
with the Patch provided in CASSANDRA-18508.
My conclusion is that- we can make two changes-
# Modify existing FileBasedSslContextFactory to support file paths for the
password (with additional configuration options like keystore_password_file and
truststore_password_file suggested in this ticket's title) AND
# Modify the JMX server utils to use SSLContext and implement
JMXSslContextFactory implementation that can allow any format like existing
implementations of the ISslContextFactory (like PEM based etc) without creating
class-bloat (too many new classes).
[~smiklosovic] [~brandon.williams] please let me know your thoughts. May be
[~djoshi] 's thought also would be helpful given his/his-teams' work on this
area.
> Security: provide keystore_password_file and truststore_password_file options
> -
>
> Key: CASSANDRA-13428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13428
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption, Local/Config
>Reporter: Bas van Dijk
>Assignee: Maulin Vasavada
>Priority: Normal
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> Currently passwords are stored in plaintext in the configuration file as in:
> {code}
> server_encryption_options:
> keystore_password: secret
> truststore_password: secret
> client_encryption_options:
> keystore_password: secret
> {code}
> This has the disadvantage that, in order to protect the secrets, the whole
> configuration file needs to have restricted ownership and permissions. This
> is problematic in operating systems like NixOS where configuration files are
> usually stored in world-readable locations.
> A secure option would be to store secrets in files (with restricted ownership
> and permissions) and reference those files from the unrestricted
> configuration file as in for example:
> {code}
> server_encryption_options:
> keystore_password_file: /run/keys/keystore-password
> truststore_password_file: /run/keys/truststore-password
> client_encryption_options:
> keystore_password_file: /run/keys/keystore-pa
[jira] [Commented] (CASSANDRA-13428) Security: provide keystore_password_file and truststore_password_file options
[
https://issues.apache.org/jira/browse/CASSANDRA-13428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17867136#comment-17867136
]
Maulin Vasavada commented on CASSANDRA-13428:
-
So since there is already a `ssl_context_factory` config which allows to plug
any mechanism to load the TLS credentials from, just to allow File paths for
passwords would be easy by adding an implementation for `ISslContextFactory`
e.g. In
[FileBasedSslContextFactory|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/FileBasedSslContextFactory.java#L276]
we can modify the FileBasedSslContext to add file path for the password .
However, the JMX is using the [Java's
SocketFactory|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/utils/JMXServerUtils.java#L98]
which is currently reading TLS credentials from the system properties even
with the Patch provided in
[CASSANDRA-18508|https://issues.apache.org/jira/browse/CASSANDRA-18508].
My conclusion is that- we can make two changes-
# Modify existing FileBasedSslContextFactory to support file paths for the
password (with additional configuration options like keystore_password_file and
truststore_password_file suggested in this ticket's title) AND
# Modify the JMX server utils to use SSLContext and implement
JMXSSLContextFactory implementation that can allow any format like existing
implementations of the ISslContextFactory (like PEM based etc) without creating
class-bloat (too many new classes).
[~smiklosovic] [~brandon.williams] please let me know your thoughts. May be
[~djoshi] 's thought also would be helpful given his/his-teams' work on this
area.
> Security: provide keystore_password_file and truststore_password_file options
> -
>
> Key: CASSANDRA-13428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13428
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption, Local/Config
>Reporter: Bas van Dijk
>Assignee: Maulin Vasavada
>Priority: Normal
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> Currently passwords are stored in plaintext in the configuration file as in:
> {code}
> server_encryption_options:
> keystore_password: secret
> truststore_password: secret
> client_encryption_options:
> keystore_password: secret
> {code}
> This has the disadvantage that, in order to protect the secrets, the whole
> configuration file needs to have restricted ownership and permissions. This
> is problematic in operating systems like NixOS where configuration files are
> usually stored in world-readable locations.
> A secure option would be to store secrets in files (with restricted ownership
> and permissions) and reference those files from the unrestricted
> configuration file as in for example:
> {code}
> server_encryption_options:
> keystore_password_file: /run/keys/keystore-password
> truststore_password_file: /run/keys/truststore-password
> client_encryption_options:
> keystore_password_file: /run/keys/keystore-password
> {code}
> This is trivial to implement and provides a big gain in security.
> So in summary I'm proposing to add the {{keystore_password_file}} and
> {{truststore_password_file}} options besides the existing
> {{keystore_password}} and {{truststore_password options}}. The former will
> take precedence over the latter.
--
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-13428) Security: provide keystore_password_file and truststore_password_file options
[
https://issues.apache.org/jira/browse/CASSANDRA-13428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17867136#comment-17867136
]
Maulin Vasavada edited comment on CASSANDRA-13428 at 7/18/24 11:40 PM:
---
So since there is already a `ssl_context_factory` config which allows to plug
any mechanism to load the TLS credentials from, just to allow File paths for
passwords would be easy by adding an implementation for `ISslContextFactory`
e.g. In
[FileBasedSslContextFactory|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/FileBasedSslContextFactory.java#L276]
we can modify the FileBasedSslContext to add file path for the password .
However, the JMX is using the [Java's
SocketFactory|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/utils/JMXServerUtils.java#L98]
which is currently reading TLS credentials from the system properties even
with the Patch provided in CASSANDRA-18508.
My conclusion is that- we can make two changes-
# Modify existing FileBasedSslContextFactory to support file paths for the
password (with additional configuration options like keystore_password_file and
truststore_password_file suggested in this ticket's title) AND
# Modify the JMX server utils to use SSLContext and implement
JMXSslContextFactory implementation that can allow any format like existing
implementations of the ISslContextFactory (like PEM based etc) without creating
class-bloat (too many new classes).
[~smiklosovic] [~brandon.williams] please let me know your thoughts. May be
[~djoshi] 's thought also would be helpful given his/his-teams' work on this
area.
was (Author: maulin.vasavada):
So since there is already a `ssl_context_factory` config which allows to plug
any mechanism to load the TLS credentials from, just to allow File paths for
passwords would be easy by adding an implementation for `ISslContextFactory`
e.g. In
[FileBasedSslContextFactory|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/FileBasedSslContextFactory.java#L276]
we can modify the FileBasedSslContext to add file path for the password .
However, the JMX is using the [Java's
SocketFactory|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/utils/JMXServerUtils.java#L98]
which is currently reading TLS credentials from the system properties even
with the Patch provided in
[CASSANDRA-18508|https://issues.apache.org/jira/browse/CASSANDRA-18508].
My conclusion is that- we can make two changes-
# Modify existing FileBasedSslContextFactory to support file paths for the
password (with additional configuration options like keystore_password_file and
truststore_password_file suggested in this ticket's title) AND
# Modify the JMX server utils to use SSLContext and implement
JMXSSLContextFactory implementation that can allow any format like existing
implementations of the ISslContextFactory (like PEM based etc) without creating
class-bloat (too many new classes).
[~smiklosovic] [~brandon.williams] please let me know your thoughts. May be
[~djoshi] 's thought also would be helpful given his/his-teams' work on this
area.
> Security: provide keystore_password_file and truststore_password_file options
> -
>
> Key: CASSANDRA-13428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13428
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption, Local/Config
>Reporter: Bas van Dijk
>Assignee: Maulin Vasavada
>Priority: Normal
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> Currently passwords are stored in plaintext in the configuration file as in:
> {code}
> server_encryption_options:
> keystore_password: secret
> truststore_password: secret
> client_encryption_options:
> keystore_password: secret
> {code}
> This has the disadvantage that, in order to protect the secrets, the whole
> configuration file needs to have restricted ownership and permissions. This
> is problematic in operating systems like NixOS where configuration files are
> usually stored in world-readable locations.
> A secure option would be to store secrets in files (with restricted ownership
> and permissions) and reference those files from the unrestricted
> configuration file as in for example:
> {code}
> server_encryption_options:
> keystore_password_file: /run/keys/keystore-password
> truststore_password_file: /run/keys/truststore-password
> client_encryption_options:
> keystore_password_file: /run/keys/keystore-password
> {code}
> This is trivial to implement and provides a big gain in security.
> So in summary I'm proposing to add the {{ke
[jira] [Commented] (CASSANDRA-13428) Security: provide keystore_password_file and truststore_password_file options
[
https://issues.apache.org/jira/browse/CASSANDRA-13428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17865824#comment-17865824
]
Maulin Vasavada commented on CASSANDRA-13428:
-
Okay, I've understood enough details to start doing some work on this. Will
keep you posted.
> Security: provide keystore_password_file and truststore_password_file options
> -
>
> Key: CASSANDRA-13428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13428
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption, Local/Config
>Reporter: Bas van Dijk
>Assignee: Maulin Vasavada
>Priority: Normal
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> Currently passwords are stored in plaintext in the configuration file as in:
> {code}
> server_encryption_options:
> keystore_password: secret
> truststore_password: secret
> client_encryption_options:
> keystore_password: secret
> {code}
> This has the disadvantage that, in order to protect the secrets, the whole
> configuration file needs to have restricted ownership and permissions. This
> is problematic in operating systems like NixOS where configuration files are
> usually stored in world-readable locations.
> A secure option would be to store secrets in files (with restricted ownership
> and permissions) and reference those files from the unrestricted
> configuration file as in for example:
> {code}
> server_encryption_options:
> keystore_password_file: /run/keys/keystore-password
> truststore_password_file: /run/keys/truststore-password
> client_encryption_options:
> keystore_password_file: /run/keys/keystore-password
> {code}
> This is trivial to implement and provides a big gain in security.
> So in summary I'm proposing to add the {{keystore_password_file}} and
> {{truststore_password_file}} options besides the existing
> {{keystore_password}} and {{truststore_password options}}. The former will
> take precedence over the latter.
--
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] [Assigned] (CASSANDRA-13428) Security: provide keystore_password_file and truststore_password_file options
[
https://issues.apache.org/jira/browse/CASSANDRA-13428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maulin Vasavada reassigned CASSANDRA-13428:
---
Assignee: Maulin Vasavada
> Security: provide keystore_password_file and truststore_password_file options
> -
>
> Key: CASSANDRA-13428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13428
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption, Local/Config
>Reporter: Bas van Dijk
>Assignee: Maulin Vasavada
>Priority: Normal
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> Currently passwords are stored in plaintext in the configuration file as in:
> {code}
> server_encryption_options:
> keystore_password: secret
> truststore_password: secret
> client_encryption_options:
> keystore_password: secret
> {code}
> This has the disadvantage that, in order to protect the secrets, the whole
> configuration file needs to have restricted ownership and permissions. This
> is problematic in operating systems like NixOS where configuration files are
> usually stored in world-readable locations.
> A secure option would be to store secrets in files (with restricted ownership
> and permissions) and reference those files from the unrestricted
> configuration file as in for example:
> {code}
> server_encryption_options:
> keystore_password_file: /run/keys/keystore-password
> truststore_password_file: /run/keys/truststore-password
> client_encryption_options:
> keystore_password_file: /run/keys/keystore-password
> {code}
> This is trivial to implement and provides a big gain in security.
> So in summary I'm proposing to add the {{keystore_password_file}} and
> {{truststore_password_file}} options besides the existing
> {{keystore_password}} and {{truststore_password options}}. The former will
> take precedence over the latter.
--
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] [Commented] (CASSANDRA-13428) Security: provide keystore_password_file and truststore_password_file options
[
https://issues.apache.org/jira/browse/CASSANDRA-13428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17864345#comment-17864345
]
Maulin Vasavada commented on CASSANDRA-13428:
-
(y)
> Security: provide keystore_password_file and truststore_password_file options
> -
>
> Key: CASSANDRA-13428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13428
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption, Local/Config
>Reporter: Bas van Dijk
>Priority: Normal
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> Currently passwords are stored in plaintext in the configuration file as in:
> {code}
> server_encryption_options:
> keystore_password: secret
> truststore_password: secret
> client_encryption_options:
> keystore_password: secret
> {code}
> This has the disadvantage that, in order to protect the secrets, the whole
> configuration file needs to have restricted ownership and permissions. This
> is problematic in operating systems like NixOS where configuration files are
> usually stored in world-readable locations.
> A secure option would be to store secrets in files (with restricted ownership
> and permissions) and reference those files from the unrestricted
> configuration file as in for example:
> {code}
> server_encryption_options:
> keystore_password_file: /run/keys/keystore-password
> truststore_password_file: /run/keys/truststore-password
> client_encryption_options:
> keystore_password_file: /run/keys/keystore-password
> {code}
> This is trivial to implement and provides a big gain in security.
> So in summary I'm proposing to add the {{keystore_password_file}} and
> {{truststore_password_file}} options besides the existing
> {{keystore_password}} and {{truststore_password options}}. The former will
> take precedence over the latter.
--
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] [Commented] (CASSANDRA-13428) Security: provide keystore_password_file and truststore_password_file options
[
https://issues.apache.org/jira/browse/CASSANDRA-13428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17864343#comment-17864343
]
Maulin Vasavada commented on CASSANDRA-13428:
-
Sounds good. Will start putting something together for the review.
> Security: provide keystore_password_file and truststore_password_file options
> -
>
> Key: CASSANDRA-13428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13428
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption, Local/Config
>Reporter: Bas van Dijk
>Priority: Normal
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> Currently passwords are stored in plaintext in the configuration file as in:
> {code}
> server_encryption_options:
> keystore_password: secret
> truststore_password: secret
> client_encryption_options:
> keystore_password: secret
> {code}
> This has the disadvantage that, in order to protect the secrets, the whole
> configuration file needs to have restricted ownership and permissions. This
> is problematic in operating systems like NixOS where configuration files are
> usually stored in world-readable locations.
> A secure option would be to store secrets in files (with restricted ownership
> and permissions) and reference those files from the unrestricted
> configuration file as in for example:
> {code}
> server_encryption_options:
> keystore_password_file: /run/keys/keystore-password
> truststore_password_file: /run/keys/truststore-password
> client_encryption_options:
> keystore_password_file: /run/keys/keystore-password
> {code}
> This is trivial to implement and provides a big gain in security.
> So in summary I'm proposing to add the {{keystore_password_file}} and
> {{truststore_password_file}} options besides the existing
> {{keystore_password}} and {{truststore_password options}}. The former will
> take precedence over the latter.
--
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-13428) Security: provide keystore_password_file and truststore_password_file options
[
https://issues.apache.org/jira/browse/CASSANDRA-13428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17862600#comment-17862600
]
Maulin Vasavada edited comment on CASSANDRA-13428 at 7/2/24 9:31 PM:
-
Can this be addressed with a similar approach mentioned in
https://issues.apache.org/jira/browse/CASSANDRA-18508 ? I think having a
pluggable credentials provider (parameterized class) make sense to provide a
unified solution to multiple passwords/credentials we have today in config
files. This will help in either fetching the credentials from a file, env
variables (e.g. K8s env vars) etc vs just files.
However by 'unified' I don't mean a 'single class'. Just a single interface and
a mechanism and have ability to write providers if needed. We must also provide
implementation to address the tickets in the concern as well.
was (Author: maulin.vasavada):
Can this be addressed with a similar approach mentioned in
https://issues.apache.org/jira/browse/CASSANDRA-18508 ? I think having a
pluggable credentials provider (parameterized class) make sense to provide a
unified solution to multiple passwords/credentials we have today in config
files. This will help in either fetching the credentials from a file, env
variables (e.g. K8s env vars) etc vs just files.
However by 'unified' I don't mean a 'single class'. Just a single interface and
a mechanism and have ability to write providers if needed.
> Security: provide keystore_password_file and truststore_password_file options
> -
>
> Key: CASSANDRA-13428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13428
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Bas van Dijk
>Priority: Normal
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> Currently passwords are stored in plaintext in the configuration file as in:
> {code}
> server_encryption_options:
> keystore_password: secret
> truststore_password: secret
> client_encryption_options:
> keystore_password: secret
> {code}
> This has the disadvantage that, in order to protect the secrets, the whole
> configuration file needs to have restricted ownership and permissions. This
> is problematic in operating systems like NixOS where configuration files are
> usually stored in world-readable locations.
> A secure option would be to store secrets in files (with restricted ownership
> and permissions) and reference those files from the unrestricted
> configuration file as in for example:
> {code}
> server_encryption_options:
> keystore_password_file: /run/keys/keystore-password
> truststore_password_file: /run/keys/truststore-password
> client_encryption_options:
> keystore_password_file: /run/keys/keystore-password
> {code}
> This is trivial to implement and provides a big gain in security.
> So in summary I'm proposing to add the {{keystore_password_file}} and
> {{truststore_password_file}} options besides the existing
> {{keystore_password}} and {{truststore_password options}}. The former will
> take precedence over the latter.
--
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-13428) Security: provide keystore_password_file and truststore_password_file options
[
https://issues.apache.org/jira/browse/CASSANDRA-13428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17862600#comment-17862600
]
Maulin Vasavada edited comment on CASSANDRA-13428 at 7/2/24 9:30 PM:
-
Can this be addressed with a similar approach mentioned in
https://issues.apache.org/jira/browse/CASSANDRA-18508 ? I think having a
pluggable credentials provider (parameterized class) make sense to provide a
unified solution to multiple passwords/credentials we have today in config
files. This will help in either fetching the credentials from a file, env
variables (e.g. K8s env vars) etc vs just files.
However by 'unified' I don't mean a 'single class'. Just a single interface and
a mechanism and have ability to write providers if needed.
was (Author: maulin.vasavada):
Can this be addressed with a similar approach mentioned in
https://issues.apache.org/jira/browse/CASSANDRA-18508 ? I think having a
pluggable credentials provider (parameterized class) make sense to provide a
unified solution to multiple passwords/credentials we have today in config
files. This will help in either fetching the credentials from a file, env
variables (e.g. K8s env vars) etc vs just files.
> Security: provide keystore_password_file and truststore_password_file options
> -
>
> Key: CASSANDRA-13428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13428
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Bas van Dijk
>Priority: Normal
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> Currently passwords are stored in plaintext in the configuration file as in:
> {code}
> server_encryption_options:
> keystore_password: secret
> truststore_password: secret
> client_encryption_options:
> keystore_password: secret
> {code}
> This has the disadvantage that, in order to protect the secrets, the whole
> configuration file needs to have restricted ownership and permissions. This
> is problematic in operating systems like NixOS where configuration files are
> usually stored in world-readable locations.
> A secure option would be to store secrets in files (with restricted ownership
> and permissions) and reference those files from the unrestricted
> configuration file as in for example:
> {code}
> server_encryption_options:
> keystore_password_file: /run/keys/keystore-password
> truststore_password_file: /run/keys/truststore-password
> client_encryption_options:
> keystore_password_file: /run/keys/keystore-password
> {code}
> This is trivial to implement and provides a big gain in security.
> So in summary I'm proposing to add the {{keystore_password_file}} and
> {{truststore_password_file}} options besides the existing
> {{keystore_password}} and {{truststore_password options}}. The former will
> take precedence over the latter.
--
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] [Commented] (CASSANDRA-13428) Security: provide keystore_password_file and truststore_password_file options
[
https://issues.apache.org/jira/browse/CASSANDRA-13428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17862602#comment-17862602
]
Maulin Vasavada commented on CASSANDRA-13428:
-
cc: [~smiklosovic] [~brandon.williams]
> Security: provide keystore_password_file and truststore_password_file options
> -
>
> Key: CASSANDRA-13428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13428
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Bas van Dijk
>Priority: Normal
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> Currently passwords are stored in plaintext in the configuration file as in:
> {code}
> server_encryption_options:
> keystore_password: secret
> truststore_password: secret
> client_encryption_options:
> keystore_password: secret
> {code}
> This has the disadvantage that, in order to protect the secrets, the whole
> configuration file needs to have restricted ownership and permissions. This
> is problematic in operating systems like NixOS where configuration files are
> usually stored in world-readable locations.
> A secure option would be to store secrets in files (with restricted ownership
> and permissions) and reference those files from the unrestricted
> configuration file as in for example:
> {code}
> server_encryption_options:
> keystore_password_file: /run/keys/keystore-password
> truststore_password_file: /run/keys/truststore-password
> client_encryption_options:
> keystore_password_file: /run/keys/keystore-password
> {code}
> This is trivial to implement and provides a big gain in security.
> So in summary I'm proposing to add the {{keystore_password_file}} and
> {{truststore_password_file}} options besides the existing
> {{keystore_password}} and {{truststore_password options}}. The former will
> take precedence over the latter.
--
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] [Commented] (CASSANDRA-13428) Security: provide keystore_password_file and truststore_password_file options
[
https://issues.apache.org/jira/browse/CASSANDRA-13428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17862601#comment-17862601
]
Maulin Vasavada commented on CASSANDRA-13428:
-
It has been a while I touched this code :( (bumps ahead :) ) but I can try to
work out a solution in next few weeks/months.
> Security: provide keystore_password_file and truststore_password_file options
> -
>
> Key: CASSANDRA-13428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13428
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Bas van Dijk
>Priority: Normal
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> Currently passwords are stored in plaintext in the configuration file as in:
> {code}
> server_encryption_options:
> keystore_password: secret
> truststore_password: secret
> client_encryption_options:
> keystore_password: secret
> {code}
> This has the disadvantage that, in order to protect the secrets, the whole
> configuration file needs to have restricted ownership and permissions. This
> is problematic in operating systems like NixOS where configuration files are
> usually stored in world-readable locations.
> A secure option would be to store secrets in files (with restricted ownership
> and permissions) and reference those files from the unrestricted
> configuration file as in for example:
> {code}
> server_encryption_options:
> keystore_password_file: /run/keys/keystore-password
> truststore_password_file: /run/keys/truststore-password
> client_encryption_options:
> keystore_password_file: /run/keys/keystore-password
> {code}
> This is trivial to implement and provides a big gain in security.
> So in summary I'm proposing to add the {{keystore_password_file}} and
> {{truststore_password_file}} options besides the existing
> {{keystore_password}} and {{truststore_password options}}. The former will
> take precedence over the latter.
--
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-13428) Security: provide keystore_password_file and truststore_password_file options
[
https://issues.apache.org/jira/browse/CASSANDRA-13428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17862601#comment-17862601
]
Maulin Vasavada edited comment on CASSANDRA-13428 at 7/2/24 9:27 PM:
-
It has been a while since I touched this code :( (bumps ahead :) ) but I can
try to work out a solution in next few weeks/months.
was (Author: maulin.vasavada):
It has been a while I touched this code :( (bumps ahead :) ) but I can try to
work out a solution in next few weeks/months.
> Security: provide keystore_password_file and truststore_password_file options
> -
>
> Key: CASSANDRA-13428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13428
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Bas van Dijk
>Priority: Normal
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> Currently passwords are stored in plaintext in the configuration file as in:
> {code}
> server_encryption_options:
> keystore_password: secret
> truststore_password: secret
> client_encryption_options:
> keystore_password: secret
> {code}
> This has the disadvantage that, in order to protect the secrets, the whole
> configuration file needs to have restricted ownership and permissions. This
> is problematic in operating systems like NixOS where configuration files are
> usually stored in world-readable locations.
> A secure option would be to store secrets in files (with restricted ownership
> and permissions) and reference those files from the unrestricted
> configuration file as in for example:
> {code}
> server_encryption_options:
> keystore_password_file: /run/keys/keystore-password
> truststore_password_file: /run/keys/truststore-password
> client_encryption_options:
> keystore_password_file: /run/keys/keystore-password
> {code}
> This is trivial to implement and provides a big gain in security.
> So in summary I'm proposing to add the {{keystore_password_file}} and
> {{truststore_password_file}} options besides the existing
> {{keystore_password}} and {{truststore_password options}}. The former will
> take precedence over the latter.
--
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] [Commented] (CASSANDRA-13428) Security: provide keystore_password_file and truststore_password_file options
[
https://issues.apache.org/jira/browse/CASSANDRA-13428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17862600#comment-17862600
]
Maulin Vasavada commented on CASSANDRA-13428:
-
Can this be addressed with a similar approach mentioned in
https://issues.apache.org/jira/browse/CASSANDRA-18508 ? I think having a
pluggable credentials provider (parameterized class) make sense to provide a
unified solution to multiple passwords/credentials we have today in config
files. This will help in either fetching the credentials from a file, env
variables (e.g. K8s env vars) etc vs just files.
> Security: provide keystore_password_file and truststore_password_file options
> -
>
> Key: CASSANDRA-13428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13428
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Bas van Dijk
>Priority: Normal
> Original Estimate: 3h
> Remaining Estimate: 3h
>
> Currently passwords are stored in plaintext in the configuration file as in:
> {code}
> server_encryption_options:
> keystore_password: secret
> truststore_password: secret
> client_encryption_options:
> keystore_password: secret
> {code}
> This has the disadvantage that, in order to protect the secrets, the whole
> configuration file needs to have restricted ownership and permissions. This
> is problematic in operating systems like NixOS where configuration files are
> usually stored in world-readable locations.
> A secure option would be to store secrets in files (with restricted ownership
> and permissions) and reference those files from the unrestricted
> configuration file as in for example:
> {code}
> server_encryption_options:
> keystore_password_file: /run/keys/keystore-password
> truststore_password_file: /run/keys/truststore-password
> client_encryption_options:
> keystore_password_file: /run/keys/keystore-password
> {code}
> This is trivial to implement and provides a big gain in security.
> So in summary I'm proposing to add the {{keystore_password_file}} and
> {{truststore_password_file}} options besides the existing
> {{keystore_password}} and {{truststore_password options}}. The former will
> take precedence over the latter.
--
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=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] [Commented] (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 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.valid
[jira] [Updated] (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:all-tabpanel
]
Maulin Vasavada updated CASSANDRA-18778:
Attachment: image-2023-09-05-21-13-06-602.png
> 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
[jira] [Commented] (CASSANDRA-18428) Implement/override equals and hashCode methods in the ServerEncryptionOptions class
[
https://issues.apache.org/jira/browse/CASSANDRA-18428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17747172#comment-17747172
]
Maulin Vasavada commented on CASSANDRA-18428:
-
Thanks [~brandon.williams] and [~smiklosovic]. Can you please provide the PR
approval/merge and move this ticket to the appropriate state?
> Implement/override equals and hashCode methods in the ServerEncryptionOptions
> class
> ---
>
> Key: CASSANDRA-18428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18428
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Maulin Vasavada
>Assignee: Maulin Vasavada
>Priority: Normal
> Labels: lhf
> Fix For: 5.x
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> We have {{equals and hashCode}} methods in
> [EncryptionOptions|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L551]
> object but not (overridden/extended) in
> [ServerEncryptionOptions.|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L600]
> Code is using the EncryptionOptions as the key in the
> [ConcurrentHashMap|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/SSLFactory.java#L84]
> in the SSLFactory.java. Hence technically we must have a equals/hashCode
> override in the ServerEncryptionOptions to account for fields that matter
> additionally (e.g. outbound_keystore/password).
> We discussed this over the [cassandra-dev slack
> channel|https://the-asf.slack.com/archives/CK23JSY2K/p1680118849081399] and
> it seems agreeable to make this change.
--
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] [Commented] (CASSANDRA-18428) Implement/override equals and hashCode methods in the ServerEncryptionOptions class
[
https://issues.apache.org/jira/browse/CASSANDRA-18428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17747165#comment-17747165
]
Maulin Vasavada commented on CASSANDRA-18428:
-
For j17 unit tests on the CI above, I see below test failures, due to failure
to create certs. I guess that is as per discussed on some other thread due to
deprecated jdk classes.
{noformat}
Testcase:
testServerSocketShouldUseKeystore(org.apache.cassandra.security.SSLFactoryTest)-.jdk17:
Caused an ERROR
[junit-timeout] Could not initialize class
org.apache.cassandra.security.SSLFactoryTest
[junit-timeout] java.lang.NoClassDefFoundError: Could not initialize class
org.apache.cassandra.security.SSLFactoryTest
[junit-timeout] at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
[junit-timeout] at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
[junit-timeout] at
java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
[junit-timeout] at
java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
[junit-timeout] at
java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480)
[junit-timeout] Caused by: java.lang.ExceptionInInitializerError: Exception
java.lang.RuntimeException: failed to create test certs [in thread "main"]
[junit-timeout] at
org.apache.cassandra.security.SSLFactoryTest.(SSLFactoryTest.java:70){noformat}
> Implement/override equals and hashCode methods in the ServerEncryptionOptions
> class
> ---
>
> Key: CASSANDRA-18428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18428
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Maulin Vasavada
>Assignee: Maulin Vasavada
>Priority: Normal
> Labels: lhf
> Fix For: 5.x
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> We have {{equals and hashCode}} methods in
> [EncryptionOptions|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L551]
> object but not (overridden/extended) in
> [ServerEncryptionOptions.|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L600]
> Code is using the EncryptionOptions as the key in the
> [ConcurrentHashMap|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/SSLFactory.java#L84]
> in the SSLFactory.java. Hence technically we must have a equals/hashCode
> override in the ServerEncryptionOptions to account for fields that matter
> additionally (e.g. outbound_keystore/password).
> We discussed this over the [cassandra-dev slack
> channel|https://the-asf.slack.com/archives/CK23JSY2K/p1680118849081399] and
> it seems agreeable to make this change.
--
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-18428) Implement/override equals and hashCode methods in the ServerEncryptionOptions class
[
https://issues.apache.org/jira/browse/CASSANDRA-18428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17747086#comment-17747086
]
Maulin Vasavada edited comment on CASSANDRA-18428 at 7/25/23 5:26 PM:
--
Thanks [~mmuzaf] for approving the
[PR#2507.|https://github.com/apache/cassandra/pull/2507] [~stefan.miklosovic]
Can we please get another review/approval and merge the PR?
was (Author: maulin.vasavada):
Thanks [~mmuzaf] for approving the
[PR#2507|https://github.com/apache/cassandra/pull/2507] [~stefan.miklosovic]
Can we please get another review/approval and merge the PR?
> Implement/override equals and hashCode methods in the ServerEncryptionOptions
> class
> ---
>
> Key: CASSANDRA-18428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18428
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Maulin Vasavada
>Assignee: Maulin Vasavada
>Priority: Normal
> Labels: lhf
> Fix For: 5.x
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> We have {{equals and hashCode}} methods in
> [EncryptionOptions|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L551]
> object but not (overridden/extended) in
> [ServerEncryptionOptions.|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L600]
> Code is using the EncryptionOptions as the key in the
> [ConcurrentHashMap|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/SSLFactory.java#L84]
> in the SSLFactory.java. Hence technically we must have a equals/hashCode
> override in the ServerEncryptionOptions to account for fields that matter
> additionally (e.g. outbound_keystore/password).
> We discussed this over the [cassandra-dev slack
> channel|https://the-asf.slack.com/archives/CK23JSY2K/p1680118849081399] and
> it seems agreeable to make this change.
--
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-18428) Implement/override equals and hashCode methods in the ServerEncryptionOptions class
[
https://issues.apache.org/jira/browse/CASSANDRA-18428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17747086#comment-17747086
]
Maulin Vasavada edited comment on CASSANDRA-18428 at 7/25/23 5:26 PM:
--
Thanks [~mmuzaf] for approving the
[PR#2507|https://github.com/apache/cassandra/pull/2507] [~stefan.miklosovic]
Can we please get another review/approval and merge the PR?
was (Author: maulin.vasavada):
Thanks [~mmuzaf] for approving the
[PR#2507|[https://github.com/apache/cassandra/pull/2507].] [~stefan.miklosovic]
Can we please get another review/approval and merge the PR?
> Implement/override equals and hashCode methods in the ServerEncryptionOptions
> class
> ---
>
> Key: CASSANDRA-18428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18428
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Maulin Vasavada
>Assignee: Maulin Vasavada
>Priority: Normal
> Labels: lhf
> Fix For: 5.x
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> We have {{equals and hashCode}} methods in
> [EncryptionOptions|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L551]
> object but not (overridden/extended) in
> [ServerEncryptionOptions.|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L600]
> Code is using the EncryptionOptions as the key in the
> [ConcurrentHashMap|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/SSLFactory.java#L84]
> in the SSLFactory.java. Hence technically we must have a equals/hashCode
> override in the ServerEncryptionOptions to account for fields that matter
> additionally (e.g. outbound_keystore/password).
> We discussed this over the [cassandra-dev slack
> channel|https://the-asf.slack.com/archives/CK23JSY2K/p1680118849081399] and
> it seems agreeable to make this change.
--
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] [Commented] (CASSANDRA-18428) Implement/override equals and hashCode methods in the ServerEncryptionOptions class
[
https://issues.apache.org/jira/browse/CASSANDRA-18428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17747086#comment-17747086
]
Maulin Vasavada commented on CASSANDRA-18428:
-
Thanks [~mmuzaf] for approving the
[PR#2507|[https://github.com/apache/cassandra/pull/2507].] [~stefan.miklosovic]
Can we please get another review/approval and merge the PR?
> Implement/override equals and hashCode methods in the ServerEncryptionOptions
> class
> ---
>
> Key: CASSANDRA-18428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18428
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Maulin Vasavada
>Assignee: Maulin Vasavada
>Priority: Normal
> Labels: lhf
> Fix For: 5.x
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> We have {{equals and hashCode}} methods in
> [EncryptionOptions|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L551]
> object but not (overridden/extended) in
> [ServerEncryptionOptions.|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L600]
> Code is using the EncryptionOptions as the key in the
> [ConcurrentHashMap|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/SSLFactory.java#L84]
> in the SSLFactory.java. Hence technically we must have a equals/hashCode
> override in the ServerEncryptionOptions to account for fields that matter
> additionally (e.g. outbound_keystore/password).
> We discussed this over the [cassandra-dev slack
> channel|https://the-asf.slack.com/archives/CK23JSY2K/p1680118849081399] and
> it seems agreeable to make this change.
--
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] [Commented] (CASSANDRA-18428) Implement/override equals and hashCode methods in the ServerEncryptionOptions class
[
https://issues.apache.org/jira/browse/CASSANDRA-18428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17746621#comment-17746621
]
Maulin Vasavada commented on CASSANDRA-18428:
-
Thanks [~mmuzaf] The reason I opened a new PR is because I rebuilt the latest
trunk locally, made sure I generate idea files ant command before I open the
IntelliJ IDE and then made changes manually again and verified that all the
style check comments you provided are addressed. Now, since anyway I closed the
older PR we can continue with the new PR. Hope thats fine. Thanks for the CI
run.
For the Jira status, what should I change to reflect its ready? Currently I
don't seem to have access to change the 'Status' field.
> Implement/override equals and hashCode methods in the ServerEncryptionOptions
> class
> ---
>
> Key: CASSANDRA-18428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18428
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Maulin Vasavada
>Assignee: Maulin Vasavada
>Priority: Normal
> Labels: lhf
> Fix For: 5.x
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> We have {{equals and hashCode}} methods in
> [EncryptionOptions|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L551]
> object but not (overridden/extended) in
> [ServerEncryptionOptions.|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L600]
> Code is using the EncryptionOptions as the key in the
> [ConcurrentHashMap|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/SSLFactory.java#L84]
> in the SSLFactory.java. Hence technically we must have a equals/hashCode
> override in the ServerEncryptionOptions to account for fields that matter
> additionally (e.g. outbound_keystore/password).
> We discussed this over the [cassandra-dev slack
> channel|https://the-asf.slack.com/archives/CK23JSY2K/p1680118849081399] and
> it seems agreeable to make this change.
--
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-18428) Implement/override equals and hashCode methods in the ServerEncryptionOptions class
[
https://issues.apache.org/jira/browse/CASSANDRA-18428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17745852#comment-17745852
]
Maulin Vasavada edited comment on CASSANDRA-18428 at 7/22/23 12:15 AM:
---
[~mmuzaf] I will close the older PR and opened a new
[PR#2507|https://github.com/apache/cassandra/pull/2507] Can you please review
that? It should have all the style fixes and removed other unnecessary
formatting changes.
And +1 on the sdkman. I love it too.
was (Author: maulin.vasavada):
[~mmuzaf] I will close the older PR and opened a new
[PR#2507|https://github.com/apache/cassandra/pull/2507] Can you please review
that? It should have all the style fixes and removed other unnecessary
formatting changes.
> Implement/override equals and hashCode methods in the ServerEncryptionOptions
> class
> ---
>
> Key: CASSANDRA-18428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18428
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Maulin Vasavada
>Assignee: Maulin Vasavada
>Priority: Normal
> Labels: lhf
> Fix For: 5.x
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> We have {{equals and hashCode}} methods in
> [EncryptionOptions|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L551]
> object but not (overridden/extended) in
> [ServerEncryptionOptions.|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L600]
> Code is using the EncryptionOptions as the key in the
> [ConcurrentHashMap|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/SSLFactory.java#L84]
> in the SSLFactory.java. Hence technically we must have a equals/hashCode
> override in the ServerEncryptionOptions to account for fields that matter
> additionally (e.g. outbound_keystore/password).
> We discussed this over the [cassandra-dev slack
> channel|https://the-asf.slack.com/archives/CK23JSY2K/p1680118849081399] and
> it seems agreeable to make this change.
--
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-18428) Implement/override equals and hashCode methods in the ServerEncryptionOptions class
[
https://issues.apache.org/jira/browse/CASSANDRA-18428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17710356#comment-17710356
]
Maulin Vasavada edited comment on CASSANDRA-18428 at 7/22/23 12:13 AM:
---
-PR: [https://github.com/apache/cassandra/pull/2269]-
See the new PR: [https://github.com/apache/cassandra/pull/2507]
was (Author: maulin.vasavada):
PR: [https://github.com/apache/cassandra/pull/2269]
> Implement/override equals and hashCode methods in the ServerEncryptionOptions
> class
> ---
>
> Key: CASSANDRA-18428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18428
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Maulin Vasavada
>Assignee: Maulin Vasavada
>Priority: Normal
> Labels: lhf
> Fix For: 5.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> We have {{equals and hashCode}} methods in
> [EncryptionOptions|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L551]
> object but not (overridden/extended) in
> [ServerEncryptionOptions.|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L600]
> Code is using the EncryptionOptions as the key in the
> [ConcurrentHashMap|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/SSLFactory.java#L84]
> in the SSLFactory.java. Hence technically we must have a equals/hashCode
> override in the ServerEncryptionOptions to account for fields that matter
> additionally (e.g. outbound_keystore/password).
> We discussed this over the [cassandra-dev slack
> channel|https://the-asf.slack.com/archives/CK23JSY2K/p1680118849081399] and
> it seems agreeable to make this change.
--
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] [Commented] (CASSANDRA-18428) Implement/override equals and hashCode methods in the ServerEncryptionOptions class
[
https://issues.apache.org/jira/browse/CASSANDRA-18428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17745852#comment-17745852
]
Maulin Vasavada commented on CASSANDRA-18428:
-
[~mmuzaf] I will close the older PR and opened a new
[PR#2507|[https://github.com/apache/cassandra/pull/2507/files].] Can you please
review that? It should have all the style fixes and removed other unnecessary
formatting changes.
> Implement/override equals and hashCode methods in the ServerEncryptionOptions
> class
> ---
>
> Key: CASSANDRA-18428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18428
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Maulin Vasavada
>Assignee: Maulin Vasavada
>Priority: Normal
> Labels: lhf
> Fix For: 5.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> We have {{equals and hashCode}} methods in
> [EncryptionOptions|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L551]
> object but not (overridden/extended) in
> [ServerEncryptionOptions.|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L600]
> Code is using the EncryptionOptions as the key in the
> [ConcurrentHashMap|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/SSLFactory.java#L84]
> in the SSLFactory.java. Hence technically we must have a equals/hashCode
> override in the ServerEncryptionOptions to account for fields that matter
> additionally (e.g. outbound_keystore/password).
> We discussed this over the [cassandra-dev slack
> channel|https://the-asf.slack.com/archives/CK23JSY2K/p1680118849081399] and
> it seems agreeable to make this change.
--
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-18428) Implement/override equals and hashCode methods in the ServerEncryptionOptions class
[
https://issues.apache.org/jira/browse/CASSANDRA-18428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17745852#comment-17745852
]
Maulin Vasavada edited comment on CASSANDRA-18428 at 7/22/23 12:11 AM:
---
[~mmuzaf] I will close the older PR and opened a new
[PR#2507|[https://github.com/apache/cassandra/pull/2507/files]] Can you please
review that? It should have all the style fixes and removed other unnecessary
formatting changes.
was (Author: maulin.vasavada):
[~mmuzaf] I will close the older PR and opened a new
[PR#2507|[https://github.com/apache/cassandra/pull/2507/files].] Can you please
review that? It should have all the style fixes and removed other unnecessary
formatting changes.
> Implement/override equals and hashCode methods in the ServerEncryptionOptions
> class
> ---
>
> Key: CASSANDRA-18428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18428
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Maulin Vasavada
>Assignee: Maulin Vasavada
>Priority: Normal
> Labels: lhf
> Fix For: 5.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> We have {{equals and hashCode}} methods in
> [EncryptionOptions|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L551]
> object but not (overridden/extended) in
> [ServerEncryptionOptions.|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L600]
> Code is using the EncryptionOptions as the key in the
> [ConcurrentHashMap|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/SSLFactory.java#L84]
> in the SSLFactory.java. Hence technically we must have a equals/hashCode
> override in the ServerEncryptionOptions to account for fields that matter
> additionally (e.g. outbound_keystore/password).
> We discussed this over the [cassandra-dev slack
> channel|https://the-asf.slack.com/archives/CK23JSY2K/p1680118849081399] and
> it seems agreeable to make this change.
--
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-18428) Implement/override equals and hashCode methods in the ServerEncryptionOptions class
[
https://issues.apache.org/jira/browse/CASSANDRA-18428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17745852#comment-17745852
]
Maulin Vasavada edited comment on CASSANDRA-18428 at 7/22/23 12:12 AM:
---
[~mmuzaf] I will close the older PR and opened a new
[PR#2507|https://github.com/apache/cassandra/pull/2507] Can you please review
that? It should have all the style fixes and removed other unnecessary
formatting changes.
was (Author: maulin.vasavada):
[~mmuzaf] I will close the older PR and opened a new [PR
2507|[https://github.com/apache/cassandra/pull/2507/files]] Can you please
review that? It should have all the style fixes and removed other unnecessary
formatting changes.
> Implement/override equals and hashCode methods in the ServerEncryptionOptions
> class
> ---
>
> Key: CASSANDRA-18428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18428
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Maulin Vasavada
>Assignee: Maulin Vasavada
>Priority: Normal
> Labels: lhf
> Fix For: 5.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> We have {{equals and hashCode}} methods in
> [EncryptionOptions|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L551]
> object but not (overridden/extended) in
> [ServerEncryptionOptions.|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L600]
> Code is using the EncryptionOptions as the key in the
> [ConcurrentHashMap|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/SSLFactory.java#L84]
> in the SSLFactory.java. Hence technically we must have a equals/hashCode
> override in the ServerEncryptionOptions to account for fields that matter
> additionally (e.g. outbound_keystore/password).
> We discussed this over the [cassandra-dev slack
> channel|https://the-asf.slack.com/archives/CK23JSY2K/p1680118849081399] and
> it seems agreeable to make this change.
--
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-18428) Implement/override equals and hashCode methods in the ServerEncryptionOptions class
[
https://issues.apache.org/jira/browse/CASSANDRA-18428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17745852#comment-17745852
]
Maulin Vasavada edited comment on CASSANDRA-18428 at 7/22/23 12:12 AM:
---
[~mmuzaf] I will close the older PR and opened a new [PR
2507|[https://github.com/apache/cassandra/pull/2507/files]] Can you please
review that? It should have all the style fixes and removed other unnecessary
formatting changes.
was (Author: maulin.vasavada):
[~mmuzaf] I will close the older PR and opened a new
[PR#2507|[https://github.com/apache/cassandra/pull/2507/files]] Can you please
review that? It should have all the style fixes and removed other unnecessary
formatting changes.
> Implement/override equals and hashCode methods in the ServerEncryptionOptions
> class
> ---
>
> Key: CASSANDRA-18428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18428
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Maulin Vasavada
>Assignee: Maulin Vasavada
>Priority: Normal
> Labels: lhf
> Fix For: 5.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> We have {{equals and hashCode}} methods in
> [EncryptionOptions|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L551]
> object but not (overridden/extended) in
> [ServerEncryptionOptions.|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L600]
> Code is using the EncryptionOptions as the key in the
> [ConcurrentHashMap|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/SSLFactory.java#L84]
> in the SSLFactory.java. Hence technically we must have a equals/hashCode
> override in the ServerEncryptionOptions to account for fields that matter
> additionally (e.g. outbound_keystore/password).
> We discussed this over the [cassandra-dev slack
> channel|https://the-asf.slack.com/archives/CK23JSY2K/p1680118849081399] and
> it seems agreeable to make this change.
--
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] [Commented] (CASSANDRA-18428) Implement/override equals and hashCode methods in the ServerEncryptionOptions class
[
https://issues.apache.org/jira/browse/CASSANDRA-18428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17745270#comment-17745270
]
Maulin Vasavada commented on CASSANDRA-18428:
-
Also, let us take the password encryption in the local files separately, I
think that has been a topic of interest in the past also.
> Implement/override equals and hashCode methods in the ServerEncryptionOptions
> class
> ---
>
> Key: CASSANDRA-18428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18428
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Maulin Vasavada
>Assignee: Maulin Vasavada
>Priority: Normal
> Labels: lhf
> Fix For: 5.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> We have {{equals and hashCode}} methods in
> [EncryptionOptions|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L551]
> object but not (overridden/extended) in
> [ServerEncryptionOptions.|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L600]
> Code is using the EncryptionOptions as the key in the
> [ConcurrentHashMap|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/SSLFactory.java#L84]
> in the SSLFactory.java. Hence technically we must have a equals/hashCode
> override in the ServerEncryptionOptions to account for fields that matter
> additionally (e.g. outbound_keystore/password).
> We discussed this over the [cassandra-dev slack
> channel|https://the-asf.slack.com/archives/CK23JSY2K/p1680118849081399] and
> it seems agreeable to make this change.
--
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] [Commented] (CASSANDRA-18428) Implement/override equals and hashCode methods in the ServerEncryptionOptions class
[
https://issues.apache.org/jira/browse/CASSANDRA-18428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17745268#comment-17745268
]
Maulin Vasavada commented on CASSANDRA-18428:
-
Hi [~mmuzaf] Thanks for the review. Will check on the suggestions soon. One
traditional issue I have faced with the changes is the 'style issue'. Currently
when I run the `ant checkstyle` it successfully completes it without errors, so
not sure how can I catch those errors before I can raise a PR.
In the past I had similar challenge and something with JDK11 was found to be an
issue skipping the actual style check. Now I am not sure what could be the
issue.
{noformat}
checkstyle:
[checkstyle] Running Checkstyle 10.8.1 on 2201 files
BUILD SUCCESSFUL
Total time: 33 seconds{noformat}
Let me see if I see anything different with a fresh local build.
> Implement/override equals and hashCode methods in the ServerEncryptionOptions
> class
> ---
>
> Key: CASSANDRA-18428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18428
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Maulin Vasavada
>Assignee: Maulin Vasavada
>Priority: Normal
> Labels: lhf
> Fix For: 5.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> We have {{equals and hashCode}} methods in
> [EncryptionOptions|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L551]
> object but not (overridden/extended) in
> [ServerEncryptionOptions.|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L600]
> Code is using the EncryptionOptions as the key in the
> [ConcurrentHashMap|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/SSLFactory.java#L84]
> in the SSLFactory.java. Hence technically we must have a equals/hashCode
> override in the ServerEncryptionOptions to account for fields that matter
> additionally (e.g. outbound_keystore/password).
> We discussed this over the [cassandra-dev slack
> channel|https://the-asf.slack.com/archives/CK23JSY2K/p1680118849081399] and
> it seems agreeable to make this change.
--
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] [Commented] (CASSANDRA-18428) Implement/override equals and hashCode methods in the ServerEncryptionOptions class
[
https://issues.apache.org/jira/browse/CASSANDRA-18428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726739#comment-17726739
]
Maulin Vasavada commented on CASSANDRA-18428:
-
[~edimitrova] [~djoshi] [~stefan.miklosovic] I know you guys must be heads down
busy but just wanted to ^^^bump^^^ this ticket since its a low-hanging fruit.
> Implement/override equals and hashCode methods in the ServerEncryptionOptions
> class
> ---
>
> Key: CASSANDRA-18428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18428
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Maulin Vasavada
>Assignee: Maulin Vasavada
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We have {{equals and hashCode}} methods in
> [EncryptionOptions|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L551]
> object but not (overridden/extended) in
> [ServerEncryptionOptions.|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L600]
> Code is using the EncryptionOptions as the key in the
> [ConcurrentHashMap|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/SSLFactory.java#L84]
> in the SSLFactory.java. Hence technically we must have a equals/hashCode
> override in the ServerEncryptionOptions to account for fields that matter
> additionally (e.g. outbound_keystore/password).
> We discussed this over the [cassandra-dev slack
> channel|https://the-asf.slack.com/archives/CK23JSY2K/p1680118849081399] and
> it seems agreeable to make this change.
--
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] [Commented] (CASSANDRA-18428) Implement/override equals and hashCode methods in the ServerEncryptionOptions class
[
https://issues.apache.org/jira/browse/CASSANDRA-18428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17715192#comment-17715192
]
Maulin Vasavada commented on CASSANDRA-18428:
-
[~edimitrova] Does this sound like a straightforward change to be considered
for a quick review/merge?
> Implement/override equals and hashCode methods in the ServerEncryptionOptions
> class
> ---
>
> Key: CASSANDRA-18428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18428
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Maulin Vasavada
>Assignee: Maulin Vasavada
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We have {{equals and hashCode}} methods in
> [EncryptionOptions|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L551]
> object but not (overridden/extended) in
> [ServerEncryptionOptions.|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L600]
> Code is using the EncryptionOptions as the key in the
> [ConcurrentHashMap|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/SSLFactory.java#L84]
> in the SSLFactory.java. Hence technically we must have a equals/hashCode
> override in the ServerEncryptionOptions to account for fields that matter
> additionally (e.g. outbound_keystore/password).
> We discussed this over the [cassandra-dev slack
> channel|https://the-asf.slack.com/archives/CK23JSY2K/p1680118849081399] and
> it seems agreeable to make this change.
--
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] [Assigned] (CASSANDRA-18428) Implement/override equals and hashCode methods in the ServerEncryptionOptions class
[
https://issues.apache.org/jira/browse/CASSANDRA-18428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maulin Vasavada reassigned CASSANDRA-18428:
---
Assignee: Maulin Vasavada
> Implement/override equals and hashCode methods in the ServerEncryptionOptions
> class
> ---
>
> Key: CASSANDRA-18428
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18428
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Maulin Vasavada
>Assignee: Maulin Vasavada
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We have {{equals and hashCode}} methods in
> [EncryptionOptions|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L551]
> object but not (overridden/extended) in
> [ServerEncryptionOptions.|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/EncryptionOptions.java#L600]
> Code is using the EncryptionOptions as the key in the
> [ConcurrentHashMap|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/SSLFactory.java#L84]
> in the SSLFactory.java. Hence technically we must have a equals/hashCode
> override in the ServerEncryptionOptions to account for fields that matter
> additionally (e.g. outbound_keystore/password).
> We discussed this over the [cassandra-dev slack
> channel|https://the-asf.slack.com/archives/CK23JSY2K/p1680118849081399] and
> it seems agreeable to make this change.
--
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] [Commented] (CASSANDRA-18124) Config parameter keystore_password should be nullable
[ https://issues.apache.org/jira/browse/CASSANDRA-18124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17713218#comment-17713218 ] Maulin Vasavada commented on CASSANDRA-18124: - Thank you both [~smiklosovic] and [~maedhroz] > Config parameter keystore_password should be nullable > - > > Key: CASSANDRA-18124 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18124 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Tibor Repasi >Assignee: Maulin Vasavada >Priority: Normal > Fix For: 5.0, 4.1.2 > > Time Spent: 11h 10m > Remaining Estimate: 0h > > Some SSL configuration may pass unencrypted private keys. PEMReader might > accept that by assuming keyPassword to be null in that case (e.g. > https://github.com/apache/cassandra/blob/f9e033f519c14596da4dc954875756a69aea4e78/src/java/org/apache/cassandra/security/PEMReader.java#L103). > Current configuration reader does not accept keystore_password parameter to > be set null or empty in the cassandra.yaml. -- 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] [Commented] (CASSANDRA-18124) Config parameter keystore_password should be nullable
[ https://issues.apache.org/jira/browse/CASSANDRA-18124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17711601#comment-17711601 ] Maulin Vasavada commented on CASSANDRA-18124: - [~smiklosovic] I prepared the backport for this ticket for 4.1 branch. Please review [this PR-2273|https://github.com/apache/cassandra/pull/2273] > Config parameter keystore_password should be nullable > - > > Key: CASSANDRA-18124 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18124 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Tibor Repasi >Assignee: Maulin Vasavada >Priority: Normal > Fix For: 4.1.x, 5.x > > Time Spent: 7h 20m > Remaining Estimate: 0h > > Some SSL configuration may pass unencrypted private keys. PEMReader might > accept that by assuming keyPassword to be null in that case (e.g. > https://github.com/apache/cassandra/blob/f9e033f519c14596da4dc954875756a69aea4e78/src/java/org/apache/cassandra/security/PEMReader.java#L103). > Current configuration reader does not accept keystore_password parameter to > be set null or empty in the cassandra.yaml. -- 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] [Commented] (CASSANDRA-18124) Config parameter keystore_password should be nullable
[ https://issues.apache.org/jira/browse/CASSANDRA-18124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17711098#comment-17711098 ] Maulin Vasavada commented on CASSANDRA-18124: - Will prepare 4.1 patch and picked-up Caleb's suggestions on the NEWS.txt. Now I guess one comment left to be resolved. > Config parameter keystore_password should be nullable > - > > Key: CASSANDRA-18124 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18124 > Project: Cassandra > Issue Type: Bug > Components: Local/Config >Reporter: Tibor Repasi >Assignee: Maulin Vasavada >Priority: Normal > Fix For: 4.1.x, 5.x > > Time Spent: 7h 10m > Remaining Estimate: 0h > > Some SSL configuration may pass unencrypted private keys. PEMReader might > accept that by assuming keyPassword to be null in that case (e.g. > https://github.com/apache/cassandra/blob/f9e033f519c14596da4dc954875756a69aea4e78/src/java/org/apache/cassandra/security/PEMReader.java#L103). > Current configuration reader does not accept keystore_password parameter to > be set null or empty in the cassandra.yaml. -- 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
