[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Security Concerns - Artemis Cluster Enforces Client Connector Configuration

Hello Community,

This is a follow up to

I set up a cluster of Artemis Brokers (2.6.0) with master/slave replication
Each broker is configured with:

1. *Acceptor*:
2. *Broker Connector* (advertised to cluster):
3. *Cluster Connector*:

Each Artemis Client (2.6.0) uses Automatic client failover and the initial
cluster connector is configured with:
1. *Client Connector: *

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:



Now, this introduces *the password masking issue*, if I understood it
correctly, according to,
masking is not supported in System Properties. Thus, you would have to pass
it in plaintext, e.g. this won't work:

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

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!