New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem: JeroMQ doesn't support authentication and security #267

Closed
trevorbernard opened this Issue Jul 15, 2015 · 12 comments

Comments

Projects
None yet
6 participants
@trevorbernard
Member

trevorbernard commented Jul 15, 2015

No description provided.

@pietsmit

This comment has been minimized.

Show comment
Hide comment
@pietsmit

pietsmit Dec 14, 2015

hi Trevor, I am very interested in tackling this problem. Does this issue not depend on the #59 issue? If so, should I rather focus on #59 first? I cannot see that anyone is working on these issues, and I am quite surprised. Am I missing something?

pietsmit commented Dec 14, 2015

hi Trevor, I am very interested in tackling this problem. Does this issue not depend on the #59 issue? If so, should I rather focus on #59 first? I cannot see that anyone is working on these issues, and I am quite surprised. Am I missing something?

@trevorbernard

This comment has been minimized.

Show comment
Hide comment
@trevorbernard

trevorbernard Dec 14, 2015

Member

Yes it does -- the latest ZMTP version is 3.1. You can find the RFC here: http://rfc.zeromq.org/spec:37. There has been plenty of interest but no one has stepped up with patches. Reading and understanding the RFC is a good start. Like you suggested, I would update to the latest supported ZMTP protocol first then add support for plain security, then curve.

Member

trevorbernard commented Dec 14, 2015

Yes it does -- the latest ZMTP version is 3.1. You can find the RFC here: http://rfc.zeromq.org/spec:37. There has been plenty of interest but no one has stepped up with patches. Reading and understanding the RFC is a good start. Like you suggested, I would update to the latest supported ZMTP protocol first then add support for plain security, then curve.

@pietsmit

This comment has been minimized.

Show comment
Hide comment
@pietsmit

pietsmit Dec 14, 2015

Thanks, it is quite a task. Hopefully I'll get permission to tackle it, as I believe it would benefit my company a lot. I am currently busy reading the spec. :)

pietsmit commented Dec 14, 2015

Thanks, it is quite a task. Hopefully I'll get permission to tackle it, as I believe it would benefit my company a lot. I am currently busy reading the spec. :)

@trevorbernard

This comment has been minimized.

Show comment
Hide comment
@trevorbernard

trevorbernard Dec 14, 2015

Member

I'd be more than happy to help out where I can

Member

trevorbernard commented Dec 14, 2015

I'd be more than happy to help out where I can

@djelenc

This comment has been minimized.

Show comment
Hide comment
@djelenc

djelenc Mar 14, 2016

Member

Hi all,

I'm very interested in moving towards ZMTP 3.0 and implementing security the features. Have you guys made any progress on this?

If not, would you be willing to cooperate in pushing this forward? I've been reading the ZMTP RFCs (1-3) and studying the engine classes, and it seems that this is no small task. However, I'd like to give this thing a bit of a push.

Member

djelenc commented Mar 14, 2016

Hi all,

I'm very interested in moving towards ZMTP 3.0 and implementing security the features. Have you guys made any progress on this?

If not, would you be willing to cooperate in pushing this forward? I've been reading the ZMTP RFCs (1-3) and studying the engine classes, and it seems that this is no small task. However, I'd like to give this thing a bit of a push.

@hintjens

This comment has been minimized.

Show comment
Hide comment
@hintjens

hintjens Mar 14, 2016

Member

I'm happy to help. It's not as big a problem as you might think. We just
need a nacl library in Java, then we can copy the logic of the C++ code, or
the libcurve library. I'm ready to help with the details. I'd guess 2-3
days of work to get the basics working.

On Mon, Mar 14, 2016 at 4:21 PM, David Jelenc notifications@github.com
wrote:

Hi all,

I'm very interested in moving towards ZMTP 3.0 and implementing security
the features. Have you guys made any progress on this?

If not, would you be willing to cooperate in pushing this forward? I've
been reading the ZMTP RFCs (1-3) and studying the engine classes, and it
seems that this is no small task. However, I'd like to give this thing a
bit of a push.


Reply to this email directly or view it on GitHub
#267 (comment).

Member

hintjens commented Mar 14, 2016

I'm happy to help. It's not as big a problem as you might think. We just
need a nacl library in Java, then we can copy the logic of the C++ code, or
the libcurve library. I'm ready to help with the details. I'd guess 2-3
days of work to get the basics working.

On Mon, Mar 14, 2016 at 4:21 PM, David Jelenc notifications@github.com
wrote:

Hi all,

I'm very interested in moving towards ZMTP 3.0 and implementing security
the features. Have you guys made any progress on this?

If not, would you be willing to cooperate in pushing this forward? I've
been reading the ZMTP RFCs (1-3) and studying the engine classes, and it
seems that this is no small task. However, I'd like to give this thing a
bit of a push.


Reply to this email directly or view it on GitHub
#267 (comment).

@djelenc

This comment has been minimized.

Show comment
Hide comment
@djelenc

djelenc Mar 14, 2016

Member

Awesome! As for crypto lib, there is a project called tweetnacl-java that we may use.

Member

djelenc commented Mar 14, 2016

Awesome! As for crypto lib, there is a project called tweetnacl-java that we may use.

@hintjens

This comment has been minimized.

Show comment
Hide comment
@hintjens

hintjens Mar 14, 2016

Member

That seems ideal, we're already using tweetnacl as the default encryption
layer in libzmq.

On Mon, Mar 14, 2016 at 5:16 PM, David Jelenc notifications@github.com
wrote:

Awesome! As for crypto lib, there is a project called tweetnacl-java
https://github.com/ianopolous/tweetnacl-java that we may use.


Reply to this email directly or view it on GitHub
#267 (comment).

Member

hintjens commented Mar 14, 2016

That seems ideal, we're already using tweetnacl as the default encryption
layer in libzmq.

On Mon, Mar 14, 2016 at 5:16 PM, David Jelenc notifications@github.com
wrote:

Awesome! As for crypto lib, there is a project called tweetnacl-java
https://github.com/ianopolous/tweetnacl-java that we may use.


Reply to this email directly or view it on GitHub
#267 (comment).

@djelenc

This comment has been minimized.

Show comment
Hide comment
@djelenc

djelenc Mar 15, 2016

Member

Ok, cool. There seems to be a consensus that ZMTP/3.0 would be nice to have, but patches are missing. Let's fix that.

Before I start messing with internals, I'd like to clear up a few questions pertaining to the JeroMQ ZMTP/2.0 implementation. So.

According to ZMTP/2.0, the backwards-compatible implementation should:

  • Send a 10-octet signature consisting of "%xFF length %x7F" where 'length' is the length of the sender's identity (0 or more octets) plus 1. The length MUST be 8 octets in network byte order. This occurs in these 3 lines.
  • Read the first octet from the other peer
    • If this octet is not %FF, then the other peer is using ZMTP/1.0.
    • If this octet is %FF, then we read nine further octets, and inspect the last octet (the 10th). If the least significant bit is 0, then the other peer is using ZMTP/1.0.
    • If the least significant bit is not 0, the peer is using ZMTP/2.0 or a later version. We read two further octets, which indicate the protocol revision, and the socket type of the other peer. We then encode/decode all further frames on that connection using the ZMTP/2.0 framing syntax. This happens here. However, the comment on line 510 would be more correct to say Protocol revision (meaning ZMTP/2), right?

Now, what confuses me are the if/elseif/else statements on lines 523, 555 and 564.

To my understanding, current JeroMQ implementation has the peer deciding whether to talk ZMTP/1 or ZMTP/2. Why do we then have three mutually exclusive branches?

Member

djelenc commented Mar 15, 2016

Ok, cool. There seems to be a consensus that ZMTP/3.0 would be nice to have, but patches are missing. Let's fix that.

Before I start messing with internals, I'd like to clear up a few questions pertaining to the JeroMQ ZMTP/2.0 implementation. So.

According to ZMTP/2.0, the backwards-compatible implementation should:

  • Send a 10-octet signature consisting of "%xFF length %x7F" where 'length' is the length of the sender's identity (0 or more octets) plus 1. The length MUST be 8 octets in network byte order. This occurs in these 3 lines.
  • Read the first octet from the other peer
    • If this octet is not %FF, then the other peer is using ZMTP/1.0.
    • If this octet is %FF, then we read nine further octets, and inspect the last octet (the 10th). If the least significant bit is 0, then the other peer is using ZMTP/1.0.
    • If the least significant bit is not 0, the peer is using ZMTP/2.0 or a later version. We read two further octets, which indicate the protocol revision, and the socket type of the other peer. We then encode/decode all further frames on that connection using the ZMTP/2.0 framing syntax. This happens here. However, the comment on line 510 would be more correct to say Protocol revision (meaning ZMTP/2), right?

Now, what confuses me are the if/elseif/else statements on lines 523, 555 and 564.

To my understanding, current JeroMQ implementation has the peer deciding whether to talk ZMTP/1 or ZMTP/2. Why do we then have three mutually exclusive branches?

@trevorbernard

This comment has been minimized.

Show comment
Hide comment
@trevorbernard

trevorbernard Mar 15, 2016

Member

One of the nice attributes of JeroMQ is that it's a direct port of libzmq v3.2.x and the heart of the logic is essentially the same, save for a few things like I/O and code evolution. Since you have a point of reference, you can follow the progression and intent from v.3.2.5 to v.4.1.4 if you wanted to (albeit slowly). You also have the various ZMTP RFCs for reference.

This has been a few years in the making, I look forward to this happening.

Member

trevorbernard commented Mar 15, 2016

One of the nice attributes of JeroMQ is that it's a direct port of libzmq v3.2.x and the heart of the logic is essentially the same, save for a few things like I/O and code evolution. Since you have a point of reference, you can follow the progression and intent from v.3.2.5 to v.4.1.4 if you wanted to (albeit slowly). You also have the various ZMTP RFCs for reference.

This has been a few years in the making, I look forward to this happening.

@tikismoke

This comment has been minimized.

Show comment
Hide comment
@tikismoke

tikismoke Dec 23, 2016

Hi all,
Domogik project is going to implement curve for security reason.
I maintain the android client wich use org.zeromq:jeromq:0.3.6 but in a soon future my apps would no more been working with such a security.

What's the status of curve implementation in jeromq?

tikismoke commented Dec 23, 2016

Hi all,
Domogik project is going to implement curve for security reason.
I maintain the android client wich use org.zeromq:jeromq:0.3.6 but in a soon future my apps would no more been working with such a security.

What's the status of curve implementation in jeromq?

@daveyarwood

This comment has been minimized.

Show comment
Hide comment
@daveyarwood

daveyarwood Jan 19, 2017

Contributor

@tikismoke If I'm not mistaken, there has been no progress on this.

Contributor

daveyarwood commented Jan 19, 2017

@tikismoke If I'm not mistaken, there has been no progress on this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment