[zeromq-dev] EncryptedSocket added to pyzmq in branch

[Pieter Hintjens]

2010/11/2 Mikael Helbo Kjær <mhk at designtech.dk>:

> I don't have an informed opinion on the python stuff, but I can't help but having to ask about all of the claims about security and stability related problems I've seen on the list recently. Does zmq have fundamental issues I am unaware off? Or is it as I thought just immaturity?

As we use 0MQ for more demanding applications that stretch wider, we
hit new problems.  That's the reason for the discussion, it's a
reflection of more people using 0MQ and pushing the envelope, not any
inherent issues.

0MQ is not as such secure, any more than its underlying transports are
secure.  That is, you don't expect TCP to do encryption, and neither
does 0MQ.  However, 0MQ applications that carry data across the
Internet _do_ need security and there's been quite a lot of talk on
how to do this.

The options seem to be:

* Use a VPN (horrid, for most people except network admins who like this)
* Use per-message encryption (as PyZMQ does but it leaves the question
of key exchange unsolved)
* Use TLS/SSL as a transport (seems cleanest but is incompatible with
multicast and the notion of hops over devices)
* Tunnel over a secure protocol, e.g. HTTPS (should be interesting,
especially to make 0MQ accessible to web applications)

Regarding stability, there are a mix of issues:

* 0MQ historically used assertions to report errors which we're
learning should be handled silently or with logging.

* 0MQ hasn't been systematically 'hardened' in terms of how robust it
is to bad input, and we have launched a competition[1] to harden it.
Dhammika Pathirana is in the lead afair with 3 points.

* 0MQ doesn't have a fully documented wire protocol so no-one has
built interoperable stacks, which is usually the way we make sure
protocols are robust.  Blame me, I was supposed to write this up but
haven't had time.

* Historically, 0MQ was geared towards a more static and smaller
network of nodes.  With 2.0, we introduced messaging patterns and the
product started to aim towards larger dynamic networks.  But things
like socket closure or handling hundreds of nodes starting up at once
didn't work properly.  These areas have now been made much more
robust, mainly driven by real applications.

* Like any developing product, new code is unstable.  We're pushing
the packaging towards a more traditional 'stable' vs 'unstable' model
so that you can explicitly download the stable release or unstable
release, or raw development version.  Today there's still no
'unstable' release as such.  Ironically this makes the product look
less stable since more people use the development master than need to.

Hope this helps.  It's always useful to have the viewpoint of someone
coming to the project, so thanks for speaking up. :)

-
Pieter Hintjens
iMatix - www.imatix.com