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:
> > 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.

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.

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