[zeromq-dev] TLS (openssl) for ZeroMQ

林宝龙 lbl52001 at gmail.com
Sat Dec 29 08:41:04 CET 2018


I'll take a look at the zap protocol again with your suggestion. It's
vacation time, I didn't get any response from my colleague about the
license.

Best regards,
Baolong


On Tue, 25 Dec 2018, 23:58 Luca Boccassi <luca.boccassi at gmail.com wrote:

> Zap allows you to fully control authentication programmatically. For
> example, every time your backend generates a new tls key, you can generate
> a curve key (with the makecert tool or the libzmq API) and associate them.
> Then when a client connect and zap gives you the curve key, you can check
> if there's a tls key associated with it. In other words, you build a bridge
> between your tls backend and the zmq channel. Or any other
> combination/implementation, as zap let's you decide how to do auth.
> Note that in all likelihood implementing this bridge is going to be much,
> much easier and quicker, and more importantly way less risky, than trying
> to add tls to zmq.
>
> On Tue, 25 Dec 2018, 22:21 林宝龙 <lbl52001 at gmail.com wrote:
>
>> I read the ZAP protocol and tried use it with curve, but just thought it
>> as authentication, didn't aware the way mapping TLS key to curve key. Just
>> wonder how to do the mapping. For example, TLS uses client authentication
>> to do the authentication, check the certification with trusted groups,
>> check the peer certification is revoked or not, what the mapping keys can
>> do? Do you know are there any examples? I may misunderstand the ZAP
>> solution you mentioned, please kindly correct me, extra documents or
>> examples are helpful.
>>
>> Best regards,
>> Baolong
>>
>>
>> On Tue, 25 Dec 2018, 21:15 Luca Boccassi <luca.boccassi at gmail.com wrote:
>>
>>> On Tue, 2018-12-25 at 21:05 +0100, 林宝龙 wrote:
>>> > I suggested to use curve directly, but as a hole system, they didn't
>>> > want
>>> > to have two key management system, TLS was there which was used by
>>> > other
>>> > node. And another reason they gave to me is the curve was not been
>>> > used so
>>> > much by big companies compare to TLS, even it's simple than TLS.
>>> > Further
>>> > more the running environment has already had OpenSSL installed, use
>>> > openssl
>>> > can lower the security libraries maintenance.
>>>
>>> First of all curve was created by expert cryptographers, and it's
>>> extensively used, so it's not really a problem. The crypto primitives
>>> are provides by libsodium, which again is a very high quality library
>>> and used by many, many applications and libraries, and will most likely
>>> be already installed everywhere.
>>>
>>> Regarding key management, are you aware that there's the ZAP protocol?
>>> You can use it to implement the key management scheme you prefer,
>>> programmatically. For example, you could map 1:1 from SSL keys to curve
>>> keys internally.
>>>
>>> > About the license problem, as you explained to me, it is a big
>>> > problem, I
>>> > saw there is an issue which was registered 2 years ago to change the
>>> > libzmq's license, but it is not coming to end. I'll check with my
>>> > colleagues how to make the license issue gone?  Come back to you when
>>> > I
>>> > have more information.
>>>
>>> Again - you *cannot* make the license issue go away. We have been
>>> trying to relicense to MPL2 for years, it will take years to finish, if
>>> ever. This is not something that can be worked around or "hacked". It's
>>> a legal issue.
>>>
>>> > Best regards,
>>> > Baolong
>>> >
>>> > On Tue, 25 Dec 2018, 12:31 Luca Boccassi <luca.boccassi at gmail.com
>>> > wrote:
>>> >
>>> > > On Tue, 2018-12-25 at 00:53 +0100, 林宝龙 wrote:
>>> > > > The problem of first option we met is that OpenSSL provides a lot
>>> > > > configurable things, for example, trust group, external
>>> > > > verification
>>> > > > callback, etc. We must add more options to sockopt to have such
>>> > > > things
>>> > > > configurable. For the callback functions, if we continue using
>>> > > > setsockopt,
>>> > > > we need to cast function pointer to void pointer and vice versa,
>>> > > > looks not
>>> > > > good.
>>> > >
>>> > > As mentioned, there is really no alternative to continue supporting
>>> > > bindings. Also, exposing a third party API/ABI again would mean
>>> > > that
>>> > > the users would need to start worrying about OpenSSL's API/ABI
>>> > > changes,
>>> > > and keep them in sync with the internal usage of the library. That
>>> > > would not be maintainable.
>>> > >
>>> > > So it looks like there are both legal and implementation problems.
>>> > > So
>>> > > let's take a step back: why is the current
>>> > > encryption/authentication
>>> > > support via CURVE and GSSAPI not sufficient? What is lacking that
>>> > > you
>>> > > need in your application?
>>> > >
>>> > > > About the licence issue, I'm not familiar with those licenses,
>>> > > > and I
>>> > > > have
>>> > > > asked someone inside my company, got the answer that I can use
>>> > > > OpenSSL in
>>> > > > libzmq with an exception, I don't know how. He said that we will
>>> > > > share the
>>> > > > code out in the end, but can't contribute back to libzmq
>>> > > > directly.
>>> > > > Does it
>>> > > > same as what you concern? Do you have more information that we
>>> > > > must
>>> > > > stop
>>> > > > using OpenSSL inside libzmq?
>>> > >
>>> > > Yes an exception is needed as I said, but not just from you: from
>>> > > every
>>> > > single copyright holder of libzmq, of which there are many. That's
>>> > > because adding an exception to the license is a change in license,
>>> > > and
>>> > > cannot legally be done unilaterally.
>>> > >
>>> > > Note that this is not only a problem for contributing code back,
>>> > > but
>>> > > also for your application. You cannot distribute those changes to
>>> > > anybody without a license change, which means you cannot give your
>>> > > application to anybody without breaching the terms of the license,
>>> > > and
>>> > > thus copyright law.
>>> > >
>>> > > > On Mon, 24 Dec 2018, 23:42 Luca Boccassi <luca.boccassi at gmail.com
>>> > > > wrote:
>>> > > >
>>> > > > > On Mon, 24 Dec 2018, 23:03 林宝龙 <lbl52001 at gmail.com wrote:
>>> > > > >
>>> > > > > > Hi,
>>> > > > > >
>>> > > > > > We are adding TLS support for ZeroMQ(based on 4.2.5). Product
>>> > > > > > reason, we
>>> > > > > > choosed OpenSSL as TLS library.
>>> > > > > >
>>> > > > > > Ask community for suggestions, which solution below is
>>> > > > > > better?
>>> > > > > > 1. Use TLS public certification, private key, etc as socket
>>> > > > > > option (set
>>> > > > > > through setsockopt), ZeroMQ manages the OpenSSL context,
>>> > > > > > one  OpenSSL
>>> > > > > > context per socket_base_t object.
>>> > > > > > 2. Use OpenSSL context as socket option(set through
>>> > > > > > setsockopt),
>>> > > > > > external
>>> > > > > > application should provide the OpenSSL context, with public
>>> > > > > > certification,
>>> > > > > > private key, etc. set in context level, all ssl connections
>>> > > > > > share
>>> > > > > > the same
>>> > > > > > configuration as the input OpenSSL context.
>>> > > > > >
>>> > > > > > At beginning we choosed the first solution, like curve, use
>>> > > > > > public
>>> > > > > > certification, private key as the socket option. But later
>>> > > > > > on, we
>>> > > > > > found the
>>> > > > > > second solution that use external OpenSSL context can make
>>> > > > > > the
>>> > > > > > ZeroMQ code
>>> > > > > > simpler, and more flexible, external application can
>>> > > > > > configure
>>> > > > > > the OpenSSL
>>> > > > > > context without change the ZeroMQ socket options.
>>> > > > > >
>>> > > > > > Welcome your comments.
>>> > > > > >
>>> > > > > > Best regards,
>>> > > > > > Baolong
>>> > > > > >
>>> > > > >
>>> > > > > The first option would be better, exposing third party API and
>>> > > > > ABI
>>> > > > > would
>>> > > > > be a nightmare, especially for bindings. O
>>> > > > >
>>> > > > > But the most important issue is that the Openssl license is not
>>> > > > > compatible
>>> > > > > with libzmq, which is licensed under the lgpl3, so I'm afraid
>>> > > > > such
>>> > > > > combination will not be legally distributable. At least not
>>> > > > > without
>>> > > > > a
>>> > > > > relicensing effort to add an exception - we are already trying
>>> > > > > that
>>> > > > > to
>>> > > > > change to mpl2 and are nowhere near done unfortunately.
>>> > > > >
>>> > > > > > _______________________________________________
>>> > > > >
>>> > > > > zeromq-dev mailing list
>>> > > > > zeromq-dev at lists.zeromq.org
>>> > > > > https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>> > > > >
>>> > > >
>>> > > > _______________________________________________
>>> > > > zeromq-dev mailing list
>>> > > > zeromq-dev at lists.zeromq.org
>>> > > > https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>> > >
>>> > > --
>>> > > Kind regards,
>>> > > Luca Boccassi_______________________________________________
>>> > > zeromq-dev mailing list
>>> > > zeromq-dev at lists.zeromq.org
>>> > > https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>> > >
>>> >
>>> > _______________________________________________
>>> > zeromq-dev mailing list
>>> > zeromq-dev at lists.zeromq.org
>>> > https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>
>>> --
>>> Kind regards,
>>> Luca Boccassi_______________________________________________
>>> zeromq-dev mailing list
>>> zeromq-dev at lists.zeromq.org
>>> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20181229/ecba9d2b/attachment.htm>


More information about the zeromq-dev mailing list