Mato, >This is mainly a problem for services connected to the public Internet, >much less for installations running on private Intranets. > >Given that the 0MQ code has not bee through any kind of security audit >(however formal/informal that may be) we should not be claiming that 0MQ >2.0.x is in any way suitable for deployment of Internet-connected services. >The FAQ entry regarding security should be updated to explicitly state >this.
Yes. It's easy to kill 0MQ nodes by sending them poisonous data. It causes assert instead of undefined (and possibly malicious) behaviour, however, it shoudn't crash at all. Instead it should log and continue. >Now, as for 0MQ 2.1.x, I think we're getting to the point where putting in >effort for making 0MQ suitable for deployment on the global Internet or >other untrusted networks is worthwhile. However, this does need to be done >systematically. > >Martin, this means that from a network point of view we should follow the >well known principle of "be conservative in what you send, and liberal in >what you accept". It should not be possible to crash 0MQ from the network >side. Agreed. Missing logging infrastructure was preventing to implement the correct behaviour. Sane logging is in a subtle way dependent on migration of sockets between threads etc. Now that we have all that functionality in the trunk, it should be easy to apply "log and disconnect" approach to poisonous connections. >This is an area that interests me so I am willing to put in effort to move >us in this direction, but IMO it's definitely 2.1.x work, or possibly even >2.2.x depending on how quickly we stabilize 2.1. Great, thanks! Martin _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
