[zeromq-dev] TLS (openssl) for ZeroMQ

[林宝龙]

Stunnel is not a community project, does it mean that commercial use and
new requirement must contact the owner of the stunnel?

Best regards,
Baolong

On Sat, 29 Dec 2018, 00:55 Mark Botner <mbotner at gmail.com wrote:

> 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 <trevor.bernard at gmail.com>
> 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 <jshanab at jfs-tech.com> 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 <luca.boccassi at gmail.com>
>> 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 <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
>> >>
>> >> --
>> >> 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
>>
> _______________________________________________
> 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/58807fdb/attachment.htm>