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
