Hi, 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 discussion.
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. Cheers, Brian -- Brian E. Granger, Ph.D. Assistant Professor of Physics Cal Poly State University, San Luis Obispo bgran...@calpoly.edu elliso...@gmail.com
_______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
