[zeromq-dev] proxying CURVE with a new NOP mechanism
Laurent Alebarde
l.alebarde at free.fr
Tue Dec 3 17:34:26 CET 2013
Great, it works ! Thanks Pieter for your help.
A pull request is following
-------- Message original --------
Sujet: Re: [zeromq-dev] proxying CURVE ?
Date : Tue, 03 Dec 2013 10:09:50 +0100
De : Laurent Alebarde <l.alebarde at free.fr>
Pour : Pieter Hintjens <ph at imatix.com>
Thanks a lot Pieter for your deep answer. I understand now why I fooled
myself: the NULL mechanism is not a "nop" mechanism.
The first solution you propose is the "normal" usage. I don't want it
since I want to load-balance the handcheck.
The second one is not ZMTP and makes things harder for load-balancing.
So, I am going to *experiment a NOP mechanism*. Other names could be
NO_SECURITY or NO_HANDCHECK or PROXY. But I think NOP is the most
meaningfull since it will allow to use any ZMTP wire protocol with it
e.g. REQ, REP, ROUTER, DEALER, etc.
Client (DEALER, CURVE) --------- (NOP, ROUTER) Proxy (ROUTER, NOP)
------------ (CURVE, DEALER) Worker
Surrogate NULL NULL NULL NULL
<--------------------------------------- Server
--------------------------------------------->
I am going to keep the surrogate feature since it remains useful for it.
Your thoughts ?
Laurent
Le 02/12/2013 18:29, Pieter Hintjens a écrit :
> On Mon, Dec 2, 2013 at 6:04 PM, Laurent Alebarde<l.alebarde at free.fr> wrote:
>
>> I took the hypothesis that only the greetings in ZMPT prevents different
>> mechanisms (say CURVE to NULL) to communicate.
> This hypothesis is really inaccurate, though. The mechanisms are not
> random strings in the handshake. They are encoded streams. It's true
> that NULL and PLAIN share the same encoding (clear text). CURVE has a
> different encoding. The handshakes themselves are also different. NULL
> and PLAIN and CURVE all use different commands with different
> meanings. There's no way to get NULL talking to CURVE by changing the
> code. The protocols are not interoperable.
>
> Let me give you one very simple example, and you may see why I'm
> asking you to explain with protocol frames, not with code.
>
> The client sends CurveZMQ HELLO to the proxy, to kick off the security
> handshake. This is a command of 200 octets with a format as described
> in RFC 26.
>
> Now the proxy must decode that command and then respond with a valid
> WELCOME command. That means, sending a valid CurveZMQ cookie.
>
> There are two ways (no more, no less, that I can see) for a proxy to
> do this. (A) it decodes the HELLO itself and creates the WELCOME
> itself. Thus it speaks CURVE, has the right keys, etc. (B) it passes
> the HELLO, unchanged to the worker, waits for a HELLO, and then passes
> that unchanged back to the client. Thus it is a plain TCP proxy that
> does not even implement the handshake. It doesn't use the NULL
> mechanism, at all.
>
> In the second option, the proxy MUST establish a connection with the
> worker invisibly and immediately as it gets a client connection,
> otherwise it cannot send on its HELLO command. Thus the end point must
> be either calculatable, or provided by the client in some way,
> _before_ the handshake, i.e. not in metadata but in the greeting
> itself.
>
> The simplest way to build such a proxy would probably be to use two
> ZMQ_STREAM sockets, one at each side.
>
> -Pieter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20131203/ab5eb430/attachment.htm>
More information about the zeromq-dev
mailing list