Re: Curl and SSL in an IMB's OnDemand environment
[...] > apparently the curl you're using is compiled with support for dynamic > ssl backends. > Try selecting NSS with https://curl.haxx.se/libcurl/c/curl_global_sslset.html I should have checked before writing. The libcurl that ships with CentOS does _not_ have support for curl_global_sslset(). rainer --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Curl and SSL in an IMB's OnDemand environment
On Tue, 10 Sep 2019, Michael Rellstab via curl-library wrote: Since several days I'm trying out to get my project to work, but I don't have any success. Giving a short overview: I have to implement a UserExit (callback routine) for the IBM's OnDemand Software. Inside this UserExit I'm using CURL (linked as shared library). This works perfectly as long as I don't use an SSL secured communication. As soon as I activate SSL (TLS1.2), there is no communication anymore. This seems to assume a few things that you didn't explain. This "OnDemand Software" calls the callback you write. How is that using libcurl? Is this software linked with libcurl already so you're just calling the libcurl API from within this callback? I'm running on a CentOS with the NSS SSL framework compiled into CURL. When I use my UserExit without OnDemand (using the same source code, but executed by my main function), CURL runs together with NSS without any problems. As soon as my code runs in the context of OnDemand, SSL is not working anymore. I expect, this has to do with IBM's OnDemand, because they are using their GsKit as SSL framework. If you're using libcurl the same way but it behaves differently depending on which TLS backend that runs, then I think we can focus on the differences in the TLS backends. The gskit code in curl is virtually unmaintained and it is likely to be the worst TLS choice of all the TLS backends libcurl supports. gskit is also not available for me to use so I can't test or improve it either. 2019-09-10 15:11:07 DEBUGCURL version:7.29.0 Can I also highlight that this is a *very* old curl version. I would be really happy, if someone has an idea how to fix this issue or getting closer to the problem. If you need more information, just ask what you need to know and I will try to give you as much detail as I can. I'd urge you to contact the OnDmeand support as they are the ones providing this API for you. And they provide a libcurl built with gskit for you. Alternatively, ask the gskit team how you can debug your gskit-using libcurl-omdemand application and its TLS connections. I don't see how we can help with that! -- / daniel.haxx.se | Get the best commercial curl support there is - from me | Private help, bug fixes, support, ports, new features | https://www.wolfssl.com/contact/ --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: Curl and SSL in an IMB's OnDemand environment
On Tue, Sep 10, 2019 at 5:19 PM Michael Rellstab via curl-library wrote: > > Hi there! > > Since several days I'm trying out to get my project to work, but I don't have > any success. > Giving a short overview: > I have to implement a UserExit (callback routine) for the IBM's OnDemand > Software. Inside this UserExit I'm using CURL (linked as shared library). > This works perfectly as long as I don't use an SSL secured communication. As > soon as I activate SSL (TLS1.2), there is no communication anymore. > > I'm running on a CentOS with the NSS SSL framework compiled into CURL. When I > use my UserExit without OnDemand (using the same source code, but executed by > my main function), > CURL runs together with NSS without any problems. As soon as my code runs in > the context of OnDemand, SSL is not working anymore. I expect, this has to do > with IBM's OnDemand, because they are using their GsKit as SSL framework. > > As you can see on my log output: > > 2019-09-10 15:11:07 DEBUGCURL version:7.29.0 [...] > 2019-09-10 15:11:07 DEBUGCURL ssl version:NSS/3.34 [...] > 2019-09-10 15:11:07 DEBUG== Info: Trying 192.168.27.108... > 2019-09-10 15:11:07 DEBUG== Info: Connected to 192.168.27.108 > (192.168.27.108) port 8443 (#0) > 2019-09-10 15:11:07 DEBUG== Info: Curl_gskit_connect_nonblocking in [...] apparently the curl you're using is compiled with support for dynamic ssl backends. Try selecting NSS with https://curl.haxx.se/libcurl/c/curl_global_sslset.html rainer --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Curl and SSL in an IMB's OnDemand environment
Hi there! Since several days I'm trying out to get my project to work, but I don't have any success. Giving a short overview: I have to implement a UserExit (callback routine) for the IBM's OnDemand Software. Inside this UserExit I'm using CURL (linked as shared library). This works perfectly as long as I don't use an SSL secured communication. As soon as I activate SSL (TLS1.2), there is no communication anymore. I'm running on a CentOS with the NSS SSL framework compiled into CURL. When I use my UserExit without OnDemand (using the same source code, but executed by my main function), CURL runs together with NSS without any problems. As soon as my code runs in the context of OnDemand, SSL is not working anymore. I expect, this has to do with IBM's OnDemand, because they are using their GsKit as SSL framework. As you can see on my log output: 2019-09-10 15:11:07 DEBUGCURL version:7.29.0 2019-09-10 15:11:07 DEBUGCURL host:x86_64-redhat-linux-gnu 2019-09-10 15:11:07 DEBUGCURL features:886BD 2019-09-10 15:11:07 DEBUGCURL ssl version:NSS/3.34 2019-09-10 15:11:07 DEBUGSuccessfully initialized Environment 2019-09-10 15:11:07 DEBUGTry to authenticate user 'nonadmin' by external authentication server 2019-09-10 15:11:07 DEBUG== Info: Trying 192.168.27.108... 2019-09-10 15:11:07 DEBUG== Info: Connected to 192.168.27.108 (192.168.27.108) port 8443 (#0) 2019-09-10 15:11:07 DEBUG== Info: Curl_gskit_connect_nonblocking in 2019-09-10 15:11:07 DEBUG== Info: curl_gskit_connect infd=34 2019-09-10 15:11:07 DEBUG== Info: curl_gskit_connect after init 35 1 2019-09-10 15:11:07 DEBUG== Info: curl_gskit_connect out 35 1 2019-09-10 15:11:07 DEBUG== Info: Curl_gskit_connect_nonblocking out 35 0 2019-09-10 15:11:07 DEBUG== Info: Closing connection 0 2019-09-10 15:11:07 DEBUG== Info: Curl_gskit_close in 2019-09-10 15:11:07 DEBUG== Info: Curl_gskit_close out 2019-09-10 15:11:07 DEBUG== Info: Curl_gskit_close in 2019-09-10 15:11:07 DEBUG== Info: Curl_gskit_close out 2019-09-10 15:11:07 DEBUG== Info: Curl_gskit_close in 2019-09-10 15:11:07 DEBUG== Info: Curl_gskit_close out 2019-09-10 15:11:07 ERRORInternal CURL call failed, CURLcode=35, CURLmsg= Although my CURL is compiled against NSS (default CentOS package), it seems CURL tries to use gskit for connecting. How can I force CURL to use NSS instead of gskit? I'm really not a professional and have too less knowledge about all this shared libraries, linking and the process context. I would be really happy, if someone has an idea how to fix this issue or getting closer to the problem. If you need more information, just ask what you need to know and I will try to give you as much detail as I can. Thanks very much in advance! Regards, Michael --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
curl_easy_perform() crash (more info)
curl 7.65.3 openssl 1.1.1b I'm still hunting for the crash bug in my application and found something interesting: "old SSL session ID is stale, removing" (marked "<-- this row") is reported twice about the same time in the verbose curl output below. Are 2 threads trying to remove the same session without locking? As far as I understand from openssl.c that should be prevented by the call to Curl_ssl_sessionid_lock(conn)? I setup a share which I initialize once with: CURLSH *sslShare; sslShare = curl_share_init(); curl_share_setopt(sslShare, CURLSHOPT_SHARE, CURL_LOCK_DATA_SSL_SESSION); and then different threads call a function which in turn set it like this before calling curl_easy_perform: CURL *curl = curl_easy_init(); (...) curl_easy_setopt(curl, CURLOPT_SHARE, sslShare); res = curl_easy_perform(curl); Should that be enough for session share protection, or do I also have to configure own locking similar to this: curl_share_setopt(sslShare, CURLSHOPT_LOCKFUNC, a_lock_cb); curl_share_setopt(sslShare, CURLSHOPT_UNLOCKFUNC, an_unlock_cb); ? Thanks, /Daniel Verbose curl output: * STATE: PERFORM => DONE handle 0x623000220508; line 1933 (connection #0) * multi_done * Connection #0 to host www.nordnet.se left intact * Expire cleared (transfer 0x623000220508) * * old SSL session ID is stale, removing < this row old SSL session ID is stale, removingDO handle 0x62300024c108; line 1566 (connection #0) * Server auth using Basic with user [removed] > GET /next/2/news/1001099919 HTTP/1.1 Stack at crash: 0x772c2605 0x772c0968 ASN1_item_free() at 0x772c0a85 OPENSSL_sk_pop_free() at 0x773fc4f0 SSL_SESSION_free() at 0x7752c3b6 Curl_ossl_session_free() at openssl.c:1,399 0x557829af Curl_ssl_kill_session() at vtls.c:374 0x5573b6d4 Curl_ssl_delsessionid() at vtls.c:398 0x5573b7b0 ossl_new_session_cb() at openssl.c:2,268 0x5578406e 0x7752582a 0x77544153 0x7753997e SSL_do_handshake() at 0x775259c4 ossl_connect_step2() at openssl.c:2,798 0x55785c78 ossl_connect_common() at openssl.c:3,608 0x557885d8 Curl_ossl_connect_nonblocking() at openssl.c:3,642 0x55788706 Curl_ssl_connect_nonblocking() at vtls.c:275 0x5573b1c4 https_connecting() at http.c:1,559 0x557469f7 Curl_protocol_connecting() at url.c:1,477 0x55750912 multi_runsingle() at multi.c:1,563 0x5571f9af curl_multi_perform() at multi.c:2,090 0x55720b16 easy_transfer() at easy.c:624 0x557181a7 easy_perform() at easy.c:718 0x55718426 curl_easy_perform() at easy.c:737 0x5571848d nordnetApi::query() at nordnetApi.cpp:255 0x556a1019 nordnetApi::newsItem() at basic_string.h:656 0x556b27ac feedProcessor::run() at feedProcessor.cpp:1,383 0x5566e7bc runThread() at Thread.cpp:25 0x5558c5e4 start_thread() at pthread_create.c:486 0x77207182 clone() at clone.S:95 0x76cd5b1f --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
