https://github.com/wesyoung/libzmq
so i've got anon[1] TLS working (sort of freakishly hacked up) against a fork of the current trunk. It's very poorly written, needs a lot of re-factoring, testing, etc etc.. Just sort of mocked it up best I could (been knee deep in perl for the last 4 years.. had to re-wire myself to write in $C). it's really shitty code, so bare with me, but for those willing to take the plunge and review: tests/tls_hwserver.cpp tests/tls_hwclient.cpp tests/test_tls.cpp all compile and appear to work (although I haven't really looked at the packets too much, just the debugging output of gnutls-2.8.6, which makes me believe it's getting encrypted :)). ./configure --with-tls will get you started. The bulk of the change is here: https://github.com/wesyoung/libzmq/commit/cdc95d04da25609d40754714ce0d73447820fd9f although a few commits after that clean up some of the test stuff. I was trying to set it up in a way where all the crypto stuff could be done at the application layer and minimal hooks could be implemented at the library layer using zmq_setsockopt, but with the const *void there, and the fact that C++ hates sending pointers to functions around too much (call-backs), it made for a bunch of code in the library itself. I'm sure there are decent ways to pull it off, just haven't figured it all out yet. Ideally, you'd be able to pass the socket a gnutls_session_t after dealing with all your security stuff (anon or x509's, etc) up in the app, then just #ifdef ZMQ_HAVE_TLS the send/recv functions at the lower level, but I dunno that it's gonna be possible in C++ based on the way the gnutls C api is laid out (haven't touched it's C++ bindings). Please make sure you've had a few beers before you test, it makes the crypto code simpler to read. The TLS doc is 3.0.13, the bindings were dev'd against gnutls-2.8.6 (debian squeeze). The api's change abit > 2.10 or so, esp when it comes to async IO callback operations in gnutls.. so if you're using anything > 2.8.6 it might not work at all. feedback welcome. it's enough code to make me wanna break out into another set of libraries (with simpler hooks into libzmq), but for prototype purposes, it … compiles. I make no claim or warranty that you won't get ow3nd by using it… :x [1] http://www.gnu.org/software/gnutls/manual/gnutls.html#Simple-client-example-with-anonymous-authentication On Jan 24, 2012, at 4:42 PM, Wes Young wrote: > Pardon the seemingly newb-ish question, > > I read through: > > http://thread.gmane.org/gmane.network.zeromq.devel/4602/focus=4640 > > and the TLS bits you'll find here: > > http://travlr.github.com/zmqirclog/110402.html#msg-77 > > and > > http://www.zeromq.org/search:site/q/encryption > > i'm digging through the code (and maybe i'm missing it), was any work > actually done in the realm of "tls://". There are a lot of reasons (in the > realm of federated networks) why this functionality would be useful. > PreludeIDS did some similar stuff with the IDMEF messaging protocol, handled > the TLS exchanges, signing, etc.. I'm looking to port this functionality into > either ZeroMQ, or an extension or.. > > just wanna make sure i'm not re-inventing the wheel somewhere.. the threads > seem to die out late 2010 and I don't see anything obvious in the change-log > (yet?). > > .. if it's already done, or being done, could someone point me in the right > direction? if not, i'll be hacking it out (via gnu-tls probably) as an addon > or something over the next few months. > > I understand all the reasoning for doing this at the message stack, etc.. and > I see SALT doing some of this (in python, at the message level) just seeing > where this thread left off before I dive in. > > thanks, > - -- > Wes > claimid.com/wesyoung > -- Wes claimid.com/wesyoung _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
