I can confirm that ZeroMQ + Stunnel works extremely well. Stunnel is very robust - I'm using it to transfer many gigabytes / day over a 0MQ pub/sub connection and have been doing so now for almost 2 years continuously.
Mark On Fri, Dec 28, 2018 at 2:50 PM Trevor Bernard <[email protected]> wrote: > Why not just use stunnel as a TLS wrapper and avoid having to modify > the zeromq code base? You are free to use OpenSSL, you don't need > another key management system that can handle the Curve25519 elliptic > curve. Configuration is likely easier than adding TLS support in > ZeroMQ. > > On Wed, Dec 26, 2018 at 5:36 PM Jeff Shanab <[email protected]> wrote: > > > > In a lot of cases (mbtls) just don't link statically and the license > issue is moot. But linking dynamically is preferred for more issues than > license. > > > > I think there are a few things here to consider, and forgive me if I get > the jargon wrong. There are other people here that are the experts. > > > > If you can use the OS implementation you can use their store, be ensured > that the most recent security updates have been applied and a well > optimized solution. (ok some of that may be up for debate, they have > security updates becasue they are most attacked.) > > > > In some countries, even on windows, you just cannot legally use OpenSSL. > So ability to swap it out is really good. > > Some devices do not play nice and you really need to talk to them with > an implementation they can work with (ie axis cameras vs ACTi cameras) > > > > If we write code into ZMQ that depends on a particular TLS > implementation, we have done it wrong! > > > > > > > > On Wed, Dec 26, 2018 at 10:11 AM Luca Boccassi <[email protected]> > wrote: > >> > >> There's also NSS from Mozilla which is under MPL and thus compatible, > >> and does not introduce any restriction on third party code. > >> > >> There are then other less-known alternatives like wolfssl, mbed ssl or > >> matrixssl which are all gpl2+ so cannot be used by proprietary products > >> or static builds. But they all have commercial licenses available, so > >> it can be used by your company for their product if they buy the > >> license. > >> > >> On Tue, 2018-12-25 at 23:35 +0100, Luca Boccassi wrote: > >> > Note that as an alternative to openssl there's gnutls which is lgpl2+ > >> > and > >> > thus is compatible - but only for dynamic linking, proprietary > >> > applications > >> > statically linking to libzmq thanks to it's exception will not be > >> > able to > >> > statically link to gnutls. > >> > > >> > On Tue, 25 Dec 2018, 21:13 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 <luca.boccassi@gmail > >> > > > > > .com > >> > > > > > 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 > >> > >> -- > >> 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
