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 <[email protected] 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 林宝龙 <[email protected] 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 <[email protected] 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 <[email protected] >>> > 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 <[email protected] >>> > > > wrote: >>> > > > >>> > > > > On Mon, 24 Dec 2018, 23:03 林宝龙 <[email protected] 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 >>> > > > > [email protected] >>> > > > > https://lists.zeromq.org/mailman/listinfo/zeromq-dev >>> > > > > >>> > > > >>> > > > _______________________________________________ >>> > > > zeromq-dev mailing list >>> > > > [email protected] >>> > > > https://lists.zeromq.org/mailman/listinfo/zeromq-dev >>> > > >>> > > -- >>> > > Kind regards, >>> > > Luca Boccassi_______________________________________________ >>> > > zeromq-dev mailing list >>> > > [email protected] >>> > > https://lists.zeromq.org/mailman/listinfo/zeromq-dev >>> > > >>> > >>> > _______________________________________________ >>> > zeromq-dev mailing list >>> > [email protected] >>> > https://lists.zeromq.org/mailman/listinfo/zeromq-dev >>> >>> -- >>> Kind regards, >>> Luca Boccassi_______________________________________________ >>> zeromq-dev mailing list >>> [email protected] >>> https://lists.zeromq.org/mailman/listinfo/zeromq-dev >>> >> _______________________________________________ >> zeromq-dev mailing list >> [email protected] >> https://lists.zeromq.org/mailman/listinfo/zeromq-dev >> > _______________________________________________ > zeromq-dev mailing list > [email protected] > https://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list [email protected] https://lists.zeromq.org/mailman/listinfo/zeromq-dev
