[zeromq-dev] More security thoughts

Brian Granger ellisonbg at gmail.com
Wed Nov 17 05:11:25 CET 2010


We (the pyzmq devs) have been thinking and talking a lot about security
lately and Min has been prototyping various ideas.  I wanted to report back
on our findings as I think they are relevant to the larger security

For the record, there are 3 main security approaches that are being
discussed for zeromq:

1.  Message layer security.  Use a regular TCP socket and
encrypt/authenticate each message part individually.
2.  Tunnel zeromq through a VPN or SSH tunnel.
3.  Make an actual SSL/TLS zeromq transport.

Min has prototyped both the (1) and (2) options.

For (1) the idea was:

* Use PyCrypto (pycrypto.org) to encrypt (AES) and authenticate (HMAC) each
message part.
* For now assume that the key distribution/exchange problem is solved (ha,
ha!) (no PKI for now).

What we found is that this approach has a significant performance penalty (I
think it was in the 3-10x range above a copying send/recv).  A performance
penalty was expected, BUT there was an aspect of this that we had not
thought about previously.  One of the core ideas in zeromq is that in
application code, a send/recv returns instantly.  This is absolutely
critical in writing high performance applications that have low latency.
 This is possible as the actual send/recv is done by zeromq in the IO
threads.  BUT, when you do message level encryption/authentication all of
the padding/encrypting/HMAC/etc is done in the application thread.  Thus,
every call to send/recv sees the performance hit.  This is a huge effect and
at least for our applications is quite difficult to tolerate.  Of course,
zeromq could be built with message level security that happens in the IO
threads, but that is very different and would require lots of low level
modifications that may affect performance in the IO threads (you don't
really want CPU bound work in IO threads).

Another thing that we realized is that message level security completely
destroys the nice non-copy send/recv capabilities of zeromq.  The reason for
this is that each message has to go through a padding/encyption/HMAC chain
and that makes multiple copies of the data.  Sure the final data can be sent
in a noncopying manner, but only after you make multiple copies first.  Part
of the difficulty is that this has to be done for each message and the
transport can't make any decisions about how to chuck the data over the
network in an efficient manner.

Summary: even if we can figure out how to make message level security
bulletproof, there are some serious performance issues.

For (2), the idea was:

* Tunnel our insecure zeromq connections over SSH tunnels.
* Rely on the security provided by SSH entirely.

This worked fairly well and the performance hit with each send/recv is
avoided.  There is still a performance penalty, but it does not occur in the
application thread.  But this approach leaves a huge gapping security hole
that we can't see how to plug.  An ssh tunnel/forwarding has to have an
insecure socket listening on the loopback of the server.  The forward
decrypts the secure data and then sends it on to the insecure socket.  The
problem with this is that *any* user on that host has full access to the
data stream and can do anything they want.  In some environments this is not
an issue, but having shared hosts with untrusted users is not that uncommon
in real life.

Summary:  tunnels have a serious security hole in the "untrusted localhost"
environment.  Tunnels only work for securing remote connections.

Alright, that is all for now.



Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20101116/30b83385/attachment.htm>

More information about the zeromq-dev mailing list