[Bro-Dev] 0MQ security considerations

[Gilbert Clark]

A few thoughts inline:

Jonathan Siwek wrote:
> 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.  

What about DTLS?  I think OpenSSL supports that, but I'm not sure how well.

I would see that protocol mapping more naturally to 0mq's idea of 
messages and / or disconnected transports, and the connection emulation 
it provides *might* work on top of 0mq.

(haven't looked at the code yet, so apologies if that's explained within :)

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

One of the things I don't like about transparently tunneling / 
encrypting like this is that an increase in network I/O also leads to an 
increase in CPU utilization; thus, as the amount of traffic bro analyzes 
increases (and its use increases), so too does the load on the system as 
a whole.  This kind of transparent encryption, then, could lead to some 
interesting behavior on older systems.

I don't know how relevant the statistics are, but this thread is still 
interesting to read: 
http://openvpn.net/archive/openvpn-users/2005-06/msg00224.html

Anyway, the point is that while a VPN might Just Work (tm) from an 
administrative / systems perspective, we'd probably need to test to see 
exactly how many events we could push through the VPN on various systems 
while simultaneously processing packets before the virtual links found 
themselves CPU-bound.

> 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; implementing anything more complex than signing seems like a bad idea.

--Gilbert