Re: [libmicrohttpd] Anyone wants openssl support in libmicrohttpd?

[Christian Grothoff]

The situation here is the same that is faced by libcurl, and IMO the
curl people made an awkward choice: the choice of backend ultimately
(seems to always) matter to advanced applications, but at configure time
one backend is chosen somewhat exclusively.  That's awkward, and
horrible for testing (need to re-configure and build a bunch of times).

For GNUnet and GNU libextractor, we've generally chosen a better
architecture: if there are multiple such choices, we use shared library
plugins (dlopen, dlsym), so at runtime the user (or software) can pick
one or more plugins that are needed.  Distributions can install any
subset of the plugins, so you'd end up with a 'libmicrohttpd' package
(which doesn't support HTTPS), and a 'libmicrohttpd-gnutls' package, a
'libmicrohttpd-FOO' package and those then depend only on the respective
gnutls or FOO backend (both in terms of linker and dependency-in package
manager).  And you can install multiple backends, and each application
can simply say which one it wants.  This also results in reasonably
clean code.

So a really nice way to do this would be to define a clear API between
MHD and some TLS backend (in the form of a header), and then move all
the OpenSSL/GnuTLS/etc.-specific code into a shared object/DLL that
implements exactly that API, and have MHD use dlopen() (or libltdl) to
access the TLS backend selected by the application.

The main application can then pick a backend (via new option) that
respects its performance/footprint/licensing requirements.

My 2 cents

Christian

On 11/05/2015 11:52 AM, Evgeny Grin wrote:
> And, if possible, keep API additions in generalized form.
> Refrain from OpenSSL-specific where possible.
> This will allow to simplify HTTPS usage from application side and allow to 
> add support for more TLS-libs in future.
> Ideally, application, that linked against libmicrohttpd, should use some 
> generic API for HTTPS and should not care about specific lib used by 
> libmicrohttpd.
> Hope that Christian will agree with me.
> 
> OpenSSL is definitely one of most widely-used TLS lib, but TLS-lib choices 
> are not limited to it:
> * NSS https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS
> * LibreSSL http://www.libressl.org/
> * mbed TLS https://tls.mbed.org/
> * MatrixSSL http://matrixssl.org/
> * Botan http://botan.randombit.net/
> * Windows SSPI 
> https://msdn.microsoft.com/ru-ru/library/windows/desktop/aa380493.aspx
> Some of them can be better in license or footprint aspects.
> 
> -- 
> Best Wishes,
> Evgeny Grin
> 
> 
> 04.11.2015, 20:40, "Christian Grothoff" <address@hidden>:
>> Ok, sounds to me like we certainly have a critical mass of volunteers to
>> review the patch, give feedback and help clean it up. So Olaf, now it's
>> just up to you to provide a convincing patch. Note that the goal should
>> be to make the result clean/neat, not the patch itself minimal. So if
>> you want/need to move existing gnutls stuff around a bit to make the
>> result nicer, that's totally fine. Oh, and please do include additional
>> testcases, especially if you add OpenSSL-specific options.
>>
>> Oh, and even if this patch happens and is acceptable, GnuTLS will remain
>> the default choice and what we will continue strongly recommend
>> distributions to use, if possible (i.e. if GnuTLS is available for the
>> platform).
>>
>> Happy hacking!
>>
>> Christian
>>
>> On 11/04/2015 05:39 PM, silvioprog wrote:
>>>  On Wed, Nov 4, 2015 at 1:21 PM, Tomas Heran <address@hidden> wrote:
>>>
>>>>  Hi.
>>>>
>>>>  Definitely count me in!
>>>>
>>>>  Cheers,
>>>>  Tomas
>>>>
>>>>  On 11/04/2015 10:50 AM, Olaf Buddenhagen wrote:
>>>>
>>>>>  Hi,
>>>>>
>>>>>  My employer considers implementing optional support for openssl as an
>>>>>  alternative to gnutls in libmicrohttpd, as CoreOS apparently doesn't
>>>>>  want to ship any SSL library besides openssl. So I need to solicit some
>>>>>  feedback on whether anyone else would be interested in having openssl
>>>>>  support?
>>>>>
>>>>>  -antrik-
>>>  Me too! +1
>