

Securing ZeroMQ: CurveZMQ protocol and implementation - zdw
http://hintjens.com/blog:36

======
w-ll
Yes, I'm pretty excited about this. I've been using ZMQ for a hot minute, and
right now its just security via obscurity. I could crack my own apps. I've
been meaning to openssl tunnel the traffic..... _shrug_ never got around to
it.

------
cbsmith
I believe the Salt Stack guys have already got a crypto implementation on top
of ZMQ that has been pretty thoroughly vetted. Might be worth checking it out
and collaborating with them.

~~~
jacques_chester
I'm not sure where I'd place my trust. The CurveZMQ is based on CurveCP, which
was designed by CJ Bernstein. CJB is a well known and generally well-regarded
cypto expert, so that gives him substantial points.

However, CurveZMQ drops a number of CurveCP features that are deemed
unimportant in the context of the ZMQ environment (to do with session handling
in UDP). Maybe that's fine ... maybe it's not. Software in general has the
annoying characteristic of spooky second-order effects appearing from "totally
unrelated" local changes; in security those second-order effects are quickly
found and exploited.

Meanwhile the Salt Stack guys seem to have stitched together some common
crypto primitives into something workable, but ... again, I'm unclear about
that. There are _so_ many ways to fuck up a crypto protocol -- I recently
spent three months iterating one and the final design was as far from the
original as oranges from unicorns.

One of the beauties of sticking with TLS, for all its inconvenience at times,
it that is under constant scrutiny.

Security is one area where Linus's Law really does seem to apply.

~~~
hintjens
The Salt security layer is great, and I've worked with Thomas Hatch on
abstracting it for wider use. We wrote this
<http://www.zeromq.org/topics:pubsub-security> some time ago.

While it's good, it has a number of weaknesses that CurveCP addresses, and
which CurveZMQ includes. The parts of CurveCP that we don't implement are
quite specifically to do with traffic control over UDP, name resolution, etc.
and not security.

The second problem with Salt's security is that it's not inside 0MQ but
layered on top. This has a number of consequences such as interoperability and
reusability.

Our goal with CurveZMQ is to put this into the 0MQ kernel so it's available
across all socket types. It will work over PUB-SUB as well as ROUTER-DEALER or
PUSH-PULL. It will work over any intermediaries and since it's basically
CurveCP, it will let you do things like migrate your clients (changing IP
address) without re-establishing the secure session.

CurveCP is really awesome and worth learning. It is really the security model
we've been looking for for years, for ZeroMQ.

The big difference between CurveZMQ and TLS is this: using TLS is complex.

One of the visions of NaCl and thus CurveCP and CurveZMQ in turn is that
simple is more secure than complex. Users can't make as many mistakes.

CurveCP and CurveZMQ are simple. The current code for CurveZMQ is under 700
lines of C (assuming you have libsodium) and I didn't try to abstract any of
the encryption calls; it's a flat implementation of the CurveCP handshake.

~~~
jacques_chester
OK, TLS is complex. But a lot of that is due to its configurability.

How would you have fared if you'd picked a simpler TLS library (PolarSSL, for
example, is meant to be embedded) and then simply defined a single ZeroMQ
configuration profile and said "that's it, that's all we're going to support"?

~~~
cbsmith
> OK, TLS is complex. But a lot of that is due to its configurability.

...and as many have noted, that configurability is the root of a lot of
security problems.

The pick one approach and say, "that's all we're going to do" might be one way
to solve the problem. I'm not sure it'd be any better.

