On Wednesday, August 30, 2017 10:40:14 PM CEST Johannes Schindelin wrote:
> Hi,
>
> 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(),

Sure. I believe that I understand the design pretty well.

> to prevent issues as you are concerned about.

It apparently does not prevent the issues because otherwise I would not be
reporting them ;-)

> Do you see a real breakage?

Yes, see my initial post in this thread. If you have a system where you can
compile libcurl against both OpenSSL and NSS, you can use the following steps
to reproduce the bug:

$ ./buildconf
$ ./configure --with-ssl --with-nss --with-default-ssl-backend=openssl --disable-tls-srp
$ make -j16
$ cd tests
$ make -j16
$ ./runtests.pl -a -p -v "HTTP NTLM auth"

8 tests fail with the following message in the verbose output:

 * unable to initialize NSS, curl_global_init() should have been called with CURL_GLOBAL_SSL or CURL_GLOBAL_ALL

> If so, it is a bug in the implementation of that design.

The problem is that the changes made to vtls/* were not reflected
in curl_ntlm_core.c, which now uses uninitialized NSS crypto backend
for the low-level crypto operation in case both NSS and OpenSSL backends
are enabled and OpenSSL is selected. In my example OpenSSL is selected
as the default crypto backend but the same will happen if you select
OpenSSL by curl_global_sslset().

In other words, only the selected crypto backend is actually initialized
but curl_ntlm_core.c does not know which crypto backend is selected and,
in some cases, tries to use an unitialized crypto backend, which fails.

Kamil

> Ciao,
> Johannes
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2017-08-31