[Bro-Dev] 0MQ security considerations

Jonathan Siwek jsiwek at ncsa.illinois.edu
Mon Jul 4 14:40:39 PDT 2011


We kind of already came to the conclusion that switching to 0MQ for the
communication framework would mean dropping Bro's built-in support for
SSL/TLS communication, but here's a summary of why (and how the best
replacement option seems to be an external tunneling solution).

With 0MQ, you're not going to have access to a fd that can be wrapped in an
OpenSSL socket BIO.  So my idea was to try replacing the socket BIO with
memory BIOs that sit in front of the 0MQ socket and wrap/unwrap application
data coming from or going onto it.  Here's the code from that attempt:

https://github.com/jsiwek/ZeroMQ-SSL-State-Machine

And the README explains why it won't work:

This was an incomplete/failed experiment in using OpenSSL as a state machine
to complete a SSL/TLS handshake over a 0MQ socket.  In summary, the handshake
can be completed for a single connection and app. data can be exchanged over
SSL/TLS for the duration of that connection, but there lies a problem in
detecting when a peer is disconnected[1][2] and thus requiring a new handshake
upon reconnection.  In 0MQ, the 'tcp' transport is considered a "disconnected"
TCP transport, meaning that the connectivity state of peers is transparent
to applications.  So this reaffirms previous 0MQ security discussions[3] that
possible approaches are:

1) Tunneling 0MQ traffic over another channel that performs SSL in some fashion
   (e.g. stunnel can work).  This relies on the user of the application to
   be able to set this up, but you get SSL/TLS strength security for "free".

2) Using a (currently non-existent) 0MQ transport implemented as some part
   of the core 0MQ library to encrypt hop-by-hop.  If this existed, drawbacks
   might be that it doesn't scale well to some of 0MQ's messaging patterns
   and would need to be implemented differently for its supported unicast
   vs. multicast transports.

3) Adding a crypto layer at the application level to wrap messages with some
   signing + encryption before sending them across the 0MQ socket.  In order
   for this to provide security features that SSL/TLS offers beyond minimal
   message authn., confidentiality, integrity, it needs to be able to use a
   key-exchange algorithm (possibly PAKE), and some form of MAC'd nonce
   (replay protection).  This doesn't seem worth the risk of rolling your own,
   best wait until 0MQ core is taught to use a well-established protocol.

[1] http://lists.zeromq.org/pipermail/zeromq-dev/2010-July/004230.html
[2] http://lists.zeromq.org/pipermail/zeromq-dev/2010-August/005285.html
[3] http://lists.zeromq.org/pipermail/zeromq-dev/2010-October/006562.html


More information about the bro-dev mailing list