[zeromq-dev] TLS (openssl) for ZeroMQ

[Jeff Shanab]

Do not tie yourself to OpenSSL. There are export restrictions! Please take
a look at how culr abstracts the TLS implementationa nd allows us to swap
in mbedtls for example.

On Mon, Dec 24, 2018 at 6:53 PM 林宝龙 <lbl52001 at gmail.com> 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.
>
> 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?
>
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20181224/6fa21c19/attachment.htm>