[zeromq-dev] ZMQ and the internet - desired/necessary features

Merijn Verstraaten merijn at inconsistent.nl
Sun Oct 21 16:57:34 CEST 2012


Hello again!

Yesterday I sent an email about doing authenticated PUBSUB by having a server side thread per client, however, after some thinking I realised there are more issues with using ZMQ on the internet and some more in-depth fixing might be desirable.

The issue with using ZMQ on the internet (or any untrusted network, really) is that anyone can just download the library and connect all sorts of untrusted code to your infrastructure that can mess with it in all sorts of undesirable ways. Some specific issues:

1) ROUTER uses identity for routing decisions, multiple connections with the same identity result in undefined behaviour. This can result in internet clients compromising security (receiving messages they shouldn't) or performing a denial of service (preventing infrastructure control message delivery).

2) Disallowing connections or disconnecting existing connections from specific clients impossible.

3) Client gets to pick subscription topics, this renders limited/non-global broadcast impossible as clients can subscribe to any topic without verification.

Now, in true open source style the response is probably "we eagerly await your patches", which is fine as I'd be happy to work on solving these issues, but I will probably need some help getting into the codebase and figured some discussion before committing a lot of my time would be smart.

The sockets I'd like to improve and/or provide internet safe replacements for are PUB, XPUB and ROUTER. The other types probably have issues on the internet too, but they don't seem as interesting in an internet setting. If anyone has suggestions for others I'm open, though.

The (server side) functionality I think is necessary for the internet is:

XPUB/PUB
  - Conditional accept of connections
  - Conditional accept of subscription
  - Forced disconnection of client
  - Forced unsubscription of client

ROUTER
  - Conditional accept of connections
  - Forced disconnection of client

In all cases the behaviour should probably be based on IP, port and identity?

I can imagine passing a callback on creation of the socket that takes an IP, port and identity (perhaps the payload of an initial special "connect" message too?) as arguments and returns whether a connection should be accepted (this lets users plug in any form of authentication they wish to use).

For subscriptions/disconnects I'm not familiar enough with the ZMQ code base to suggest anything.

Thoughts? Comments? Helpful offers to get me acquainted with the ZMQ source?

--
Merijn


More information about the zeromq-dev mailing list