If someone has unauthorized access to the broker such that they can change
its configuration then he *already* has access to the unencrypted data in
memory and on disk (i.e. in the journal). I see this mainly as a problem
to be solved at one of the many other security layers before the broker is
ever involved.
Justin
On Sun, Aug 12, 2018 at 1:25 PM, Sinaver Idris <sinavercri...@gmail.com>
wrote:
> 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
>
