[zeromq-dev] TLS (openssl) for ZeroMQ

Steven McCoy steven.mccoy at miru.hk
Tue Dec 25 17:47:46 CET 2018


A common workaround is to dynamically pull in OpenSSL at runtime.  Have a
context option that specifies the OpenSSL “.so” or “.dll” path and cache
the required API inside a struct or similar.

—
Steve-o

On Tue, Dec 25, 2018 at 6:30 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20181225/c54472f9/attachment.htm>


More information about the zeromq-dev mailing list