Hi Kamil,

On Wed, 6 Sep 2017, Kamil Dudka wrote:

> On Thursday, August 31, 2017 9:36:10 AM CEST Kamil Dudka via
> curl-library wrote:
> > On Wednesday, August 30, 2017 10:40:14 PM CEST Johannes Schindelin wrote:
> > >
> > > 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.

I finally got around to test this here, and it would seem that the tests
fail here, too. Just to make sure: the reported failures are

TESTFAIL: These test cases failed: 176 2025 2028 2029 2030 2031 2032 2033

> > 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.
>
> Basically the same problem is reported in the following pull request:
>
> https://github.com/curl/curl/pull/1848
>
> ... although the proposed changes would solve it only partially.

This PR has been updated, and I offered a further fixup that I hope will
be part of the PR before merging. It is available as `ntlmmulti` branch at
https://github.com/dscho/curl.

Would you mind testing again with that branch?

Thank you,
Johannes
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2017-09-09