> Thus, you would have to pass it in plaintext, e.g. this won't work: -Dorg.apache.activemq.ssl.keyStorePassword=ENC(...)?
That's correct. Currently neither "org.apache.activemq.ssl.keyStorePassword" nor "org.apache.activemq.ssl.trustStorePassword" support password masking. This follows the convention established by the more general "javax.net.ssl.keyStorePassword" and "javax.net.ssl.trustStorePassword" from the JVM which also don't support masking. > How about *sslEnabled, enabledProtocols, enabledCipherSuites* params? Is there any way to override these on the client as well? No. > It is a security concern if a broker can force a client to use sslEnabled false, same applies to a broker forcing weaker TLS protocol and cipher suites. I'm not entirely convinced there is a real cause for concern here. If the broker itself is configured to allow non-SSL traffic when it shouldn't that seems like a broker configuration problem. The bottom line is that the broker must be configured appropriately. There's only so much software can do to mitigate risk when finally it's up to administrators to configure the software appropriately. The same goes for weaker cipher suites. Configure the broker to use the proper cipher-suites and the clients won't have a choice but to use those as well. You can already set parameters like "useTopologyForLoadBalancing" to false (to prevent using the cluster topology for connection load balancing) or "ha" to false (to prevent using the cluster-defined backup), but those obviously have side-effects you may not like (i.e. no client-side connection load-balancing or fail-over). Justin On Thu, Aug 2, 2018 at 6:40 AM, Sinaver Idris <sinavercri...@gmail.com> wrote: > Hello Community, > > This is a follow up to https://issues.apache.org/jira/browse/ARTEMIS-1157 > > I set up a cluster of Artemis Brokers (2.6.0) with master/slave replication > configuration. > Each broker is configured with: > > 1. *Acceptor*: > *sslEnabled=true;needClientAuth=true,enabledProtocols=...; > enabledCipherSuites=...,keyStorePath=...;keyStorePassword=...; > trustStorePath=...;trustStorePassword=...* > 2. *Broker Connector* (advertised to cluster): > *sslEnabled=true,enabledProtocols=...;enabledCipherSuites=..., > keyStorePath=...;keyStorePassword=...;trustStorePath=...; > trustStorePassword=...* > 3. *Cluster Connector*: > *sslEnabled=true,enabledProtocols=...;enabledCipherSuites=..., > keyStorePath=...;keyStorePassword=...;trustStorePath=...; > trustStorePassword=...* > > Each Artemis Client (2.6.0) uses Automatic client failover and the initial > cluster connector is configured with: > 1. *Client Connector: * > *sslEnabled=true;verifyHost=true,enabledProtocols=...; > enabledCipherSuites=...,keyStorePath=...;keyStorePassword=...; > trustStorePath=...;trustStorePassword=...* > > All passwords are masked. > > Now, in cluster mode, the *Client Connector* configuration will be used by > Artemis Client only to discover Cluster Topology (which will include > *Broker > Connector* configuration). > After Discovery, Artemis Client will use *Broker Connector* configuration > to connect to the broker. > > The first issue: KeyStorePath/Password & TrustStorePath/Password on > different broker/client would be different, thus need some way to override. > The second issue: Broker will share KS password in Topology Information > > The proposed solution from *ARTEMIS-1157 JIRA *comments - don't configure > KS/TS params in acceptors/connectors URLs (on Broker and Client), but set > these via System Properties/JVM Args: > > *-Dorg.apache.activemq.ssl.keyStore=...* > *-Dorg.apache.activemq.ssl.keyStorePassword=...* > > *-Dorg.apache.activemq.ssl.trustStore=...* > *-Dorg.apache.activemq.ssl.trustStorePassword...* > > Now, this introduces *the password masking issue*, if I understood it > correctly, according to > https://activemq.apache.org/artemis/docs/2.6.0/masking-passwords.html, > masking is not supported in System Properties. Thus, you would have to pass > it in plaintext, e.g. this won't work: > -Dorg.apache.activemq.ssl.keyStorePassword=ENC(...)? > > How about *sslEnabled, enabledProtocols, enabledCipherSuites* params? Is > there any way to override these on the client as well? > It is a security concern if a broker can force a client to use sslEnabled > false, same applies to a broker forcing weaker TLS protocol and > cipher suites. > > I understood from *ARTEMIS-1157 JIRA* comments that Cluster Topology might > be heterogeneous, and clients should be told what connector configuration > to use. > But if you know that your Cluster Topology connector configuration is > homogeneous, in that case it would be nice if there was a client/broker > param, like *<enforce-cluster-connector-config>false</enforce-cluster- > connector-config>, > *which implies don't use the configuration from in Cluster Topology > information, use configuration from initial cluster connector (except > *host:por**t*). > > Would it require a lot of efforts to support such a flag? I can try to > tweak it myself, but not sure if it won't affect other functionality, or > whether it is only one jar that requires the change so that I don't have to > build all sources. > > I do agree, that for the most use cases these security concerns are > not serious, but sometimes you would like to have the control. > > Please advise! > > Thanks, > Sinaver >
