Security Concerns - Artemis Cluster Enforces Client Connector Configuration

[Sinaver Idris <si...@gmail.com>]

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

Re: Security Concerns - Artemis Cluster Enforces Client Connector Configuration

[Justin Bertram <jb...@apache.org>]

> 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 <si...@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
>