We are currently exploring solutions to push/synchronize data between two systems (in two separate networks) in "near" realtime.

The solutions are somewhat limited :

  1. Some kind of RPC mechanism : HTTP "Web Hooks", gRPC, SOAP, whatever...
  2. Sharing some kind of message-broker/queue (Apache Kafka, RabbitMQ, NATS...)

From what I see, most message brokers are like databases : they implement a minimal level of security (credentials and sometimes TLS), but they rely mostly on network security.

Question : is there a secure way to share a message-broker between two remote systems ?

All I could think of was either putting an application in front (hence falling back to solution 1.), or using a VPN.


Anything that secures the connection will do.

The most compatible option using a layer 2 or 3 VPN to connect the two systems (and firewall them properly against anything else): unless you're dealing with a really, really strange protocol, you're pretty much guaranteed to be able to make it work. The downside is that it can be delicate to configure that on cloud-based hosts and it doesn't scale well.

The second option, as you guessed, is to use TLS connection between machines, That will depend heavily on what software you're using but TLS is a pretty common option and you can usually configure it for mutual x509 certificate authentication which will give you a pretty good level of security. Note that all HTTP-based RPC will be able to use TLS and that forcing mutual authentication is typically a matter of configuration.

The third option is to enable encryption inside the message broker architecture. Contrary to what you wrote, many message broker system will allow you to configure end-to-end encryption at the message level. It's usually not really trivial to implement, however. for instance, take a look at WebSphere's help page on that subject. The main advantage of that option is that messages are encrypted at rest as well as in transit and that means the message queue system doesn't have to be able to decrypt the messages themselves: all it requires i^s the correct enveloppe data.

| improve this answer | |
  • All solutions (RPC & Message Brokers clients) use TCP underneath, so we should be able to make any solution work. I was worried about the "exposure" the message broker would receive with solutions 2 & 3 : would it be sufficient to just place a firewall in front of the broker ? maybe I don't know broker implementations well enough, but I had doubt about their robustness against DoS attacks ? – Michael Técourt Feb 14 '18 at 11:47
  • I'm not sure what you're talking about: either you'r talking about the operational security of the message broker (in which case the solution is application-dependent but usually means using firewalls) or the more general issue of the message broker being able to see then content of the traffic (which is why you might want to go for the 3rd solution) – Stephane Feb 15 '18 at 9:59
  • Pretty much all message brokers will require some form of authentication or, at least, proof of authorization before accepting a message – Stephane Feb 15 '18 at 10:00
  • I was speaking about operational security, the appropriate term would be hardening. I was wondering if firewalls were sufficient combined with the 2nd and/or 3rd solution (i.e. without a VPN), or if there were some specific hardening techniques and best practices. – Michael Técourt Feb 16 '18 at 15:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.