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:
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 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 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.