Thanks, Justin.
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.
I will give an example. Let's say you have 2 Artemis nodes configured with
master and slave replication.
All the nodes were configured with SSL, proper TLS version, cipher suites,
etc. So everything works as expected.
Now, somehow a hacker modifies configuration on the slave node, either
after it was deployed, or during the upgrade, or there might be different
scenarios, etc.
Slave shares its topology information as non-ssl with the master node
(master node doesn't verify this connection since backup acceptor is in
backup mode) then master node simply stores it in the cache.
Artemis clients will get it as backup topology as well.
Then hacker has some way to overload the network, or introduce network
partition, so that master becomes not available, backup node comes alive
and client re-connects to it.
Afterwards, you have the man in the middle who can do whatever he wants. He
can either simply profile non-encrypted network, or he can additionally
hack local DNS, or leverage some vulnerability in it, and redirect traffic
to its own server.
Realistically, it might be hard for a hacker to do that, but it is still
possible.
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).
You are right, I still want to leverage client-side fail-over, since it
works really nice under the hood :)
I experimented a little: was able to override received non-ssl topology
information on the client-side by introducing a callback in
ServerLocatorImpl:
public interface OverrideReceivedTopologyConfigurationCallBack {
void override(TransportConfiguration live, TransportConfiguration backup);
}
This callback is called in *notifyNodeUp(...)* method and overrides
received topology by calling *override(...)*.
In the callback I would simply do sth like:
serverLocator.setOverrideReceivedTopologyPairConfigurationCallBack((live,
backup) -> {
if (live != null) {
live.getParams().putAll(getDefaultSSLConnectionParams());
}
if (backup != null) {
backup.getParams().putAll(getDefaultSSLConnectionParams());
}
});
Now, with the server-side, I was able to apply the same ServerLocatorImpl
change, now the problem is that ServerLocatorImpl is used in many places,
so I had to set this callback in a bunch of classes like
*ClusterConnectionImpl,
BackupManager, ClusterController, ClusterManager,
SharedNothingLiveActivation*. And master-slave replication would work fine,
but I am not sure about other possible use cases.
Ideally, I imagine in broker.xml under <cluster-connection> you could set
property
<overrideReceivedTopologySSLConfiguration>sslEnabled=true;....</overrideReceivedTopologySSLConfiguration>,
and it will override any ssl related configuration of received topology.
Would you guys be interested in this change, we could contribute, but
probably would need some suggestions, since the code base is huge, and we
might miss some use cases.
Thanks,
Sinaver
