curl / Mailing Lists / curl-library / Single Mail


Re: Enabled multiple SSL backends

From: Johannes Schindelin <>
Date: Wed, 30 Aug 2017 22:40:14 +0200 (CEST)


On Wed, 30 Aug 2017, Kamil Dudka wrote:

> On Wednesday, August 30, 2017 10:14:06 AM CEST Daniel Stenberg wrote:
> > On Wed, 30 Aug 2017, Kamil Dudka wrote:
> >
> > > This is caused by using NSS for the crypto operations despite only
> > > OpenSSL was initialized. Should the switch work for SSL only or
> > > should it work for the low-level crypto operations, too?
> >
> > I don't think it matters, does it? The low level crypto functions
> > should just work no matter which backend that provides them. Swichting
> > or not, I mean.
> >
> > > A lightweight solution would be to fix curl_ntlm_core.c such that it
> > > uses crypto operations from the default SSL/crypto backend. This
> > > would fix the breakage in the most common case. However, NTLM would
> > > still break if the SSL backend was switched at run-time.
> >
> > We're selecting which SSL backend to use before anything used curl for
> > the first time and then never again for the process life time - at
> > least for the time being.
> The point is that it does not work well if you initialize only OpenSSL
> (either be it compile-time default, or run-time selected backend) and
> then you try to use low-level crypto from NSS.

The current design relies on the fact that OpenSSL is initialized when
OpenSSL is used, and NSS is initialized when NSS is used. The SSL backend
is not (yet) a per-session choice. It is a global choice before you call
curl_global_init(), to prevent issues as you are concerned about.

Do you see a real breakage? If so, it is a bug in the implementation of
that design.

Received on 2017-08-30