ZMQ encryption: how to know when the handshake failed?

Question

Context

• I am trying to implement properly the encryption with ZMQ 4.2.1 (this commit actually)
• I read the very interesting article from Pieter Hintjens (here), where he describe the handshake procedure between a client and a server.
• I have:
  • a client, who knows the server's public key + its own key pair
  • a server, who knows only its own key pair

Use case

I want to know when my client is using wrong keys (one or more of the three he knows are wrong).

When playing this use case, today the connection fails as expected but I have no way to know if the connection failed because of the encryption handshake failed.

Nb.: when I set the good keys, the connection works just fine as well

Settings

The server:

• Socket: ZMQ_ROUTER, binds on a TCP endpoint.
• Parameters:
  • ZMQ_CURVE_SERVER = 1
  • ZMQ_CURVE_SECRETKEY = the private key of the server
  • ZMQ_CURVE_PUBLICKEY = the public key of the server
• A monitoring socket is listening to the events of the router socket.

The client:

• Socket: ZMQ_DEALER, connects to the server's TCP endpoint.
• Parameters:
  • ZMQ_CURVE_SERVER = 0
  • ZMQ_CURVE_SERVERKEY = the public key of the server
  • ZMQ_CURVE_SECRETKEY = the private key of the client
  • ZMQ_CURVE_PUBLICKEY = the public key of the client
• A monitoring socket is listening to the events of the dealer socket.

Behaviour

I am running my server and client in two simple console applications, the client uses a wrong server's publioc key.

Here are the log traces of the monitoring socket of the server:

Router monitoring event: MONITOR_STARTED - 
Router monitoring event: LISTENING - tcp://0.0.0.0:20100
Router monitoring event: ACCEPTED - tcp://0.0.0.0:20100
Router monitoring event: DISCONNECTED - tcp://0.0.0.0:20100
Router monitoring event: ACCEPTED - tcp://0.0.0.0:20100
Router monitoring event: DISCONNECTED - tcp://0.0.0.0:20100
Router monitoring event: ACCEPTED - tcp://0.0.0.0:20100
Router monitoring event: DISCONNECTED - tcp://0.0.0.0:20100
Router monitoring event: ACCEPTED - tcp://0.0.0.0:20100
Router monitoring event: DISCONNECTED - tcp://0.0.0.0:20100
Router monitoring event: ACCEPTED - tcp://0.0.0.0:20100

And so on...

Here is the console traces that just happened when executing this use case:

CURVE I: cannot open client HELLO -- wrong server key?
CURVE I: cannot open client HELLO -- wrong server key?
CURVE I: cannot open client HELLO -- wrong server key?
CURVE I: cannot open client HELLO -- wrong server key?
CURVE I: cannot open client HELLO -- wrong server key?

And so on...

Here are the log traces of the client's monitoring socket:

Dealer monitoring event: MONITOR_STARTED - 
Dealer monitoring event: CONNECT_DELAYED - tcp://127.0.0.1:20100
Dealer monitoring event: CONNECTED - tcp://127.0.0.1:20100
Dealer monitoring event: DISCONNECTED - tcp://127.0.0.1:20100
Dealer monitoring event: CONNECT_RETRIED - tcp://127.0.0.1:20100
Dealer monitoring event: CONNECT_DELAYED - tcp://127.0.0.1:20100
Dealer monitoring event: CONNECTED - tcp://127.0.0.1:20100
Dealer monitoring event: DISCONNECTED - tcp://127.0.0.1:20100
Dealer monitoring event: CONNECT_RETRIED - tcp://127.0.0.1:20100
Dealer monitoring event: CONNECT_DELAYED - tcp://127.0.0.1:20100
Dealer monitoring event: CONNECTED - tcp://127.0.0.1:20100
Dealer monitoring event: DISCONNECTED - tcp://127.0.0.1:20100
Dealer monitoring event: CONNECT_RETRIED - tcp://127.0.0.1:20100
Dealer monitoring event: CONNECT_DELAYED - tcp://127.0.0.1:20100
Dealer monitoring event: CONNECTED - tcp://127.0.0.1:20100
Dealer monitoring event: DISCONNECTED - tcp://127.0.0.1:20100

And so on...

I tried very quickly to follow the code of ZMQ from the trace "cannot open client HELLO -- wrong server key" (see this file), but it doesn't looks like there is a specific handling for handshake fails, or maybe I didn't went far enough in the code to find it out...

Does any one has already faced that case and found out how to know if the keys we use are good or not? To me this information seems kind of important, but maybe it's not provided by ZMQ for security reason? I'm really not an expert in security...

Answer 1

Edit 2018-02-05:

The feature is stable and available since version 4.2.1, still in the DRAFT section of the API.

See the documentation:

ZMQ_EVENT_HANDSHAKE_FAILED

The ZMTP security mechanism handshake failed. The event value is unspecified. NOTE: in DRAFT state, not yet available in stable releases.

ZMQ_EVENT_HANDSHAKE_SUCCEED

The ZMTP security mechanism handshake succeeded. The event value is unspecified. NOTE: in DRAFT state, not yet available in stable releases.

---

Edit 2017-01-01:

The pull request has been merged into the master branch of libzmq. It is now possible to get the handshake status, using the monitoring events:

• ZMQ_EVENT_HANDSHAKE_SUCCEED is raised, once the encryption handshake succeed
• ZMQ_EVENT_HANDSHAKE_FAILED is raised, when it failed

However this feature is still not stable, you need to compile libzmq using the preprocessor directive ZMQ_BUILD_DRAFT_API.

---

Original answer (2016-12-29):

There is currently no proper feature for this purpose.

There is an open feature request on libzmq github.