[zeromq-dev] Confirm authentication and retrieve metadata?

Stephen Eley sfeley at gmail.com
Sat Apr 11 22:21:48 CEST 2015 

On Apr 11, 2015, at 7:54 AM, Pieter Hintjens <ph at imatix.com> wrote:
> 
> I guess it could be useful to expose this per socket; however imagine
> you're connecting to thousands of peers and one of those peers has a
> bad certificate. Do you now stop, and handle the error, or ignore it
> and treat that peer as if it was offline?

Good question -- which is why I think it would be better to give the user the *option* of detecting it and let them decide if it matters to their use case.

I've thought about it, and I think the minimal change to expose this this would simply be adding a new event to zmq_socket_monitor. I will submit an issue to this effect, and if I can dust off my C skills and understand the code well enough, will eventually do it and submit a pull request.


Have Fun,
Steve Eley



> 
> "ezmq" is already the name of the native Erlang stack,
> https://github.com/zeromq/ezmq. You might use a different name. You
> can usually repurpose defunct names, though it's wise to add a version
> number so people know it's a different thing.
> 
> -Pieter
> 
>> On Thu, Apr 9, 2015 at 7:01 PM, Steve Eley <sfeley at gmail.com> wrote:
>> 
>> On Apr 9, 2015, at 1:07 AM, Pieter Hintjens <ph at imatix.com> wrote:
>> 
>> zmq_connect doesn't expose security failures at all. These are visible
>> in the server side via ZAP, and in the client side via monitor events.
>> Also we added logging to libzmq in such cases.
>> 
>> 
>> Thanks Peter. That confirms my observations and answers my first question
>> very well. But it leaves the second question open and possibly more
>> important. If socket monitoring is the intended means for a client to detect
>> that its security handshake failed, how does the client distinguish between
>> a security-related disconnect and any other disconnect?  What's the unique
>> event pattern that makes a security failure visible?
>> 
>> Also, while it's less important, I'd appreciate any insight on my metadata
>> question. Pre-4.1, is there any way for the server _or_ client to retrieve
>> the user ID or application-specific metadata returned by the ZAP handler?
>> Post-4.1, is there any way to get it without a message being sent?
>> 
>> 
>> You should read the CZMQ zauth class, and look at the examples on
>> http://hintjens.com/blog:48. These will help a lot probably.
>> 
>> 
>> Thank you. I read your series of blog posts a number of times before
>> starting on the design.  When I ran into these unknowns I did read the
>> relevant CZMQ code, as well as the libzmq test cases and the
>> curve_client.cpp and plain_client.cpp source.  All of that was very helpful
>> in understanding the critical path, and I can see that client sockets do
>> detect handshake failures and set a 'mechanism_t::error' status (though the
>> error reason appears to be thrown away). What I can't figure out is how to
>> see that error status using libzmq API calls so that I can tell the
>> application what went wrong. Am I correct in concluding that there is no
>> way?  If so, is this by design, or would an issue calling for a way to
>> expose handshake status be well-received?
>> 
>> 
>> If you are building a new Ruby wrapper then look at
>> https://github.com/methodmissing/rbczmq.
>> 
>> 
>> Thanks once again. I'm a little familiar with that library (and somewhat
>> more so with ffi-rzmq), and it appears to be good at what it does despite
>> lacking security features. The reason I'm rolling my own instead of
>> contributing to it is a philosophical difference. I don't want a Ruby
>> library that acts like a C library, with the usage semantics that implies.
>> I want one that feels like Ruby -- initializer options, duck-typed messages,
>> 'receive' methods that accept code blocks, etc. -- and I want all of the
>> setup and teardown to be completely transparent.  The default Context
>> springs into existence when the first Socket is created. Sockets are cleanly
>> closed on garbage collection.  Stuff like that.
>> 
>> If you're interested you can find my work-in-progress at
>> https://github.com/sfeley/ezmq . It all works pretty well except for the 4.x
>> features I'm implementing now. (I know it needs to be renamed; there's a gem
>> naming conflict that didn't exist when I started it. Unfortunately, all the
>> 'obvious' names for a Ruby 0mq gem have already been taken, so unless one of
>> the defunct gems is willing to give up their name, I'll probably have to
>> call it something less than obvious. Such is life.)
>> 
>> Have Fun,
>> Steve Eley
>> 
>> 
>> -Pieter
>> 
>> On Thu, Apr 9, 2015 at 3:59 AM, Stephen Eley <sfeley at gmail.com> wrote:
>> 
>> Hi all,
>> 
>> I'm trying to build a Ruby wrapper with simple support for some of 0mq's
>> newer features, including encryption and authentication. I believe I have a
>> pretty good handle on the socket options and how the ZAP authentication
>> handler needs to work. However, I've been conceptually hung up on how to
>> detect and pass failures back to the user application, and scouring Google
>> and the source code hasn't helped.
>> 
>> My questions:
>> 
>> 1. The RFCs all say that server sockets are to disconnect in the event of a
>> CURVE key or ZAP authentication failure. But the zmq_connect call doesn't
>> appear to wait for any of that, and even with ZMQ_IMMEDIATE set it doesn't
>> seem to have any relevant error codes. Short of setting up a
>> zmq_socket_monitor and listening for disconnect events in a dedicated
>> thread, is there any way I can figure out on the client end that a
>> connection never cleared security?
>> 
>> 2. If I did take the zmq_socket_monitor route, is there any way to tell the
>> difference between a ZMQ_EVENT_DISCONNECTED that happened because of a CURVE
>> or ZAP failure and one that happened for any other reason?
>> 
>> 3. The ZAP protocol defines a frame for a user ID "for use by applications."
>> There's another one for metadata with similar intent. However, I can't
>> figure out how the application is supposed to get ahold of that data. I see
>> that 0mq 4.1 has a zmq_msg_gets function for metadata on every message, but
>> that doesn't help current production users, and querying on received
>> messages seems like an odd place to get connection-level information that's
>> given exactly once. If that future functionality is the only way, how does
>> one go about getting metadata on a send-only socket?
>> 
>> Apologies if these are dumb questions and I missed something obvious. And
>> thanks in advance for any tips or pointers to example code.
>> 
>> 
>> Have Fun,
>> Steve Eley
>> 
>> 
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> 
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> 
>> 
>> 
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20150411/01d41157/attachment.htm>

More information about the zeromq-dev mailing list