[nanomsg] end-to-end security
- From: Drew Crawford <drew@xxxxxxxxxxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Tue, 11 Mar 2014 07:59:54 -0500
Hello folks,
I’ve written before to gauge the interest level on landing encryption support
to nanomsg.
After my last post, I tentatively decided to go with a libzmq-based solution.
However, for reasons outside the scope of this list, that hasn’t gone as well
as I’d liked, and I’m now thinking about nanomsg once again.
The problem is important enough that I actually have time to work on it, and
due to time constraints I’m going to settle on some solution in the next few
days. The only open question at this point is whether I’m going to land
patches in nanomsg, or whether I’m going to be doing some kind of private
solution, like a private fork or wrap of some library. I’d prefer the former
if possible.
I’d like to make a concrete proposal for comment. As far as I can tell, there
hasn’t been further discussion on the subject of encryption since my last post.
Here is what I’m thinking on design decisions:
End-to-end, “well-above-transport-layer” security. Don’t get me wrong, there
is a good case for transport-layer security. Zeromq has used it with some
success. I use it right now. The thing is, I’ve become convinced it’s the
wrong approach for **my** set of problems.
Zeromq's support gets poor when you move out of TCP transport. It would be a
lot of work for them to support IPC, for example, which I’m mildly interested
in. I suspect that UDP is somewhat challenging as well, which is a long-term
goal. Doing security work near the surface means it’s completely decoupled
from adding new transports, which is good if you want new transports, and also
good if you want security to work with them.
Patches to the cryptography require deep knowledge of zeromq internals, and the
people with the right knowledge are often busy. When minor features to
security are needed it creates major delays. If security sits near the surface
it requires knowledge of mostly public APIs and so cryptography work can
proceed without scheduling meetings with core committers to understand the
obscure internal design of the day.
Focus on REQ/REP, and maybe DEVICE, which are the sockets I’m interested in.
The other socket types can wait until somebody is sufficiently motivated to
make security work for those socket types.
Stick close to CurveCP where sensible, but allow for some experimentation.
Maybe the user can choose from several competing security mechanisms.
Here are some concrete API proposals:
New values for nn_getsockopt, nn_setsockopt:
Setting/getting various public and private keys
Applications would rely on these values for security, so it is important that a
remote attacker cannot set arbitrary socket options
Switching between authentication mechanisms, if several are supported, or using
no authentication.
Reporting authentication errors. A logical place to do this would be from
nn_connect, however, my understanding is that the transport connection isn’t
established at that time. One possibility is to introduce a separate
nn_authenticate function, called after nn_connect and before send/receive.
Another possibility is to report errors from send/receive themselves.
On a socket that has opted in to security, nn_send and nn_recv encrypt,
decrypt, and verify messages as appropriate. Sockets not opted in are
unaffected.
New APIs nn_send_raw and nn_recv_raw allow unencrypted reads/writes on sockets
that have opted into security
The entire enterprise should be documented for the forseeable future as
experimental, unstable and not for use on nukes
Again, I’m volunteering to land all of this, pretty soonish, if this is
basically sounding like a patch you want to merge. And I am happy to collect
feedback and refine some of these details as appropriate.
However, I’d rather not bikeshed on this, as I have done enough bikeshedding
about encryption features for message-queue projects to last many lifetimes ;)
So if this work overall isn’t feeling right for core, I am completely happy to
find a place to do it that isn’t in core. My feelings won’t be hurt.
Drew
Other related posts:
