[zeromq-dev] EncryptedSocket added to pyzmq in branch

Brian Granger ellisonbg at gmail.com
Tue Nov 2 14:41:05 CET 2010


Pieter,

Thanks for the summary...

> 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)

This is definitely not an option for us.

> * Use per-message encryption (as PyZMQ does but it leaves the question
> of key exchange unsolved)

For most of the apps we are developing, we have system for
distributing the secrets used by the ciphers.  But this is an issue.

> * Use TLS/SSL as a transport (seems cleanest but is incompatible with
> multicast and the notion of hops over devices)

I think that both Min and I feel that this is the best approach, or
minimally, that there should be an SSL/TLS transport in 0MQ that
encrypts before sending and decrypts upon receiving.  If this approach
is used, there is not an issue with multihop, but there is the
overhead of having to encrypt/decrypt on each hop.  But, you are right
that multicast may have issues.  In this picture, the encryption
happens below most of the 0MQ layer.

> * Tunnel over a secure protocol, e.g. HTTPS (should be interesting,
> especially to make 0MQ accessible to web applications)

We already have examples of doing this using the Tornado based
eventloop in zmq.  It is also possible to do a 0MQ -> websocket bridge
quite easily.

Cheers,

Brian

> 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
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com



More information about the zeromq-dev mailing list