[zeromq-dev] TLS (openssl) for ZeroMQ

Luca Boccassi luca.boccassi at gmail.com
Tue Dec 25 23:35:41 CET 2018


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 <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20181225/1898682d/attachment.htm>


More information about the zeromq-dev mailing list