Yes, one of our options is to create our own wrapper library by compile libcurl on our repository. Anything that I need to know for this option. thanks,
On Tue, Mar 19, 2013 at 8:52 AM, cnm marketing <[email protected]>wrote: > >A hack could be to use libcurl without SSL use and setup stunnel as a > last resort to avoid using SSL on your many layers. > [cnm] What can exact libcurl or other routines/options be used, please > give a bit more details if it is possible. > > > On Sat, Mar 16, 2013 at 8:32 PM, cnm marketing > <[email protected]>wrote: > >> >> Here is a very brief overview of the layers: >> -------------------------------------------- >> | Service Layer | >> | | >> -------------------------------------------- >> | | >> ------------------- ----------------------- >> | AAA Layer | ... | Others Layer | >> | | | | >> ------------------- --------------------- >> | >> ------------------- >> | API Layers | ... >> | | >> ------------------- >> >> Service layer - a daemon/service, it also contains many libraries (i.e. >> *.so on Linux), this layer use bsafe ssl, as well as openssl, this layer >> has its own bsafe and openssl libraries come with this layer. >> >> AAA Layer - plugin libraries (i.e. *.so), is loaded by Service Layer. >> This layer load libcurl via dlopen()/dlclose() and use libcurl routines to >> communicate to remote server to retrieve data. This layer do not do any >> openssl by itself (except libcurl invoke openssl). I believe libcurl will >> use the openssl in the local system ??!! >> >> API layers - many libraries, these libraries are linked into AAA Layer >> via compile link time. This layer uses openssl to communicate to the other >> remote server (not the same remote server in AAA Layer), it has its own >> openssl library come with this layer >> >> When the service layer starts, AAA Layer gets loaded into the service >> layer. Before libcurl in AAA Layer is called, the API Layers are getting >> loaded by AAA Layer, in the meantime, the openssl in API layers is getting >> call first. Then the libcurl in AAA Layer gets call and produce the error >> ""*error:0506706E:Diffie-Hellman routines:GENERATE_KEY:key size too small" >> in libcurl output file via option CURLOPT_STDERR. >> >> However, on the same Linux system, I create a small program and uses the >> EXACT libcurl routines with dlopen()/dlclose(), this program retrieves the >> data from the same remote server just fine with CURLOPT_SSL_VERIFYPEER to 1 >> or 0, i.e. with cert.pem or without cert.pem. >> >> Hopefully this is clear enough. >> >> On Sat, Mar 16, 2013 at 5:16 PM, cnm marketing >> <[email protected]>wrote: >> >>> We'll try your way and Yang's way to debug and see what the data looks >>> like in the openssl layer. >>> >>> I am a bit confused by Yang's comment "The problem is in the certificate >>> you are using which does not have a long enough Diffie-Hellman key.", as I >>> said the same error message shows up when I use the cert.pemm file or skip >>> the verifypeer check. How can the problem relate to the certificate if we >>> don't pass in cert.pem to libcurl. >>> >>> We also notice the comment in the link >>> http://comments.gmane.org/gmane.comp.encryption.openssl.user/43777 for >>> "FIPS-compliant constraints of the SSL stack there". The other group are >>> still trying to verify this. >>> >>> If I understand your comment correctly, are you saying libcurl uses the >>> openssl in the system (Linux) and OUR underneath software layers may use >>> other openssl from other area??! >>> >>> >>> >>> On Sat, Mar 16, 2013 at 7:33 AM, cnm marketing >>> <[email protected]>wrote: >>> >>>> Thanks for the suggestion Oscar! >>>> >>>> We are still doing research on the link >>>> http://comments.gmane.org/gmane.comp.encryption.openssl.user/43777 >>>> providered by Daniel, because it invokes other groups' work, it will >>>> take a while. >>>> >>>> In the meantime, we'd like to know in libcurl: >>>> 1. How do you invoke openssl in the case of CURLOPT_SSL_VERIFYPEER 0 >>>> and 1. Do you suppose to skip CA verification if CURLOPT_SSL_VERIFYPEER is >>>> 0, if it does, the how come you still have "*error:0506706E:Diffie-Hellman >>>> routines:GENERATE_KEY:key size too small*". Or this error has nothing >>>> to do with CURLOPT_SSL_VERIFYPEER ?! I am a bit confused by Yang's comment >>>> on checking the openssl key. >>>> 2. libcurl does not have any option to reset the key size, correct? >>>> 3. Since we have other layers that invokes openssl or/and bsafe, in our >>>> software we are not the one first get loaded into the memory, so the >>>> openssl from libcurl will use the openssl loaded by other layer. The reason >>>> that we think this may have something to do with the mixed openssl is - we >>>> create a small program that use the exact libcurl routine, this program >>>> works perfectly fine. It fails with the error >>>> "*error:0506706E:Diffie-Hellman >>>> routines:GENERATE_KEY:key size too small*" when we integrate this >>>> piece of code to our software layer. Any thought on this. >>>> >>>> On Fri, Mar 15, 2013 at 4:26 PM, cnm marketing < >>>> [email protected]> wrote: >>>> >>>>> >*error:0506706E:Diffie-Hellman routines:GENERATE_KEY:key size too >>>>> small * >>>>> >libcurl does not fool around with certificate contents nor keys. >>>>> [cnm] libcurl uses openssl, that error message comes from openssl. >>>>> >The problem is in the certificate you are using which does not have a >>>>> long enough Diffie-Hellman key. >>>>> [cnm] I don't understand what you are refering to, please give a bit >>>>> more details. When we use libcurl, we don't set Diffie-Hellman key. We are >>>>> getting the same Diffie-Hellman error message for both >>>>> CURLOPT_SSL_VERIFYPEER >>>>> to 1 and CURLOPT_SSL_VERIFYPEER to 0. Please refer to my previous >>>>> email thread!! >>>>> >>>>> >>>>> On Fri, Mar 15, 2013 at 2:59 PM, cnm marketing < >>>>> [email protected]> wrote: >>>>> >>>>>> >error:0506706E:Diffie-Hellman routines:GENERATE_KEY:key size too >>>>>> small >>>>>> 1. When libcurl uses Diffie-Hellman, does libcurl hardcode the >>>>>> Diffie-Hellman key and the length? >>>>>> 2. Does libcurl have an option that allow libcurl user to re-set the >>>>>> Diffie-Hellman key length? >>>>>> We are still wondering (90% convinced) whether the error message has >>>>>> something to do with the openssl that is getting loaded from another >>>>>> layer. >>>>>> When the openssl is being loaded by another layer, libcurl is trying to >>>>>> use >>>>>> that openssl context and find the key size (set by libcurl) is too small >>>>>> compare to the key set by another layer. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Mar 15, 2013 at 2:00 PM, cnm marketing < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> >What SSL implementation is your libcurl using? How is the SSL >>>>>>> stack build and how did you build libcurl? >>>>>>> [cnm] >>>>>>> 1. I am not sure if I understand your first question, we use >>>>>>> libcurl, if libcurl uses ssl, then we use whatever is on the system, in >>>>>>> our >>>>>>> case, we use openssl. >>>>>>> 2. We use dlopen()/dlsym()/dlclose() to load libcurl library. This >>>>>>> is the ONLY way that we can fit libcurl into our software layers. There >>>>>>> are >>>>>>> at least 3 different layers in our layer that uses openssl, we are not >>>>>>> the >>>>>>> first one to be loaded. >>>>>>> >>>>>>> On Fri, Mar 15, 2013 at 12:59 PM, cnm marketing < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> >libcurl is able to use 9 different SSL implementation as its SSL >>>>>>>> library for SSL connections. And yes, OpenSSL is one of them. >>>>>>>> [cnm] Does libcurl statically link ssl or dynamically load those >>>>>>>> ssl? >>>>>>>> >>>>>>>> >I've never seen the error message >>>>>>>> *> * error:0506706E:Diffie-Hellman routines:GENERATE_KEY:key size >>>>>>>> too small >>>>>>>> * >>>>>>>> [cnm] If you believe this error message is NOT from libcurl itself, >>>>>>>> then I believe this error message is from the openssl routines that the >>>>>>>> libcurl invokes. The question is why openssl throw this error, and in >>>>>>>> what >>>>>>>> situation (from libcurl code) this error will be throwed from libcurl? >>>>>>>> >What SSL implementation is your libcurl using? How is the SSL >>>>>>>> stack build and how did you build libcurl? >>>>>>>> [cnm] >>>>>>>> 1. I am not sure if I understand your first question, we use >>>>>>>> libcurl, if libcurl uses ssl, then we use whatever is on the system, >>>>>>>> in our >>>>>>>> case, we use openssl. >>>>>>>> 2. We use dlopen()/dlsym()/dlclose() to load libcurl library. This >>>>>>>> is the ONLY way that we can fit libcurl into our software layers. I >>>>>>>> need to >>>>>>>> check with other groups and see how many they use ssl in their layers. >>>>>>>> I'll >>>>>>>> get back to you on this. >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Mar 15, 2013 at 10:44 AM, cnm marketing < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> How that can be? Does libcurl also use openssl? >>>>>>>>> >>>>>>>>> From my code, I only invoke libcurl routines. Again the following >>>>>>>>> output are the libcurl output by using CURLOPT_VERBOSE and >>>>>>>>> CURLOPT_STDERR. >>>>>>>>> When setting CURLOPT_SSL_VERIFYHOST to 1, we got the debug1.txt >>>>>>>>> output, when setting CURLOPT_SSL_VERIFYHOST to 0, we get the >>>>>>>>> debug.txt output >>>>>>>>> >>>>>>>>> >>>>>>>>> [root@l2se0132 bin]# more /debug1.txt >>>>>>>>> >>>>>>>>> * About to connect() to l2se0060.lss.emc.com port 8443 (#0) >>>>>>>>> >>>>>>>>> * Trying 10.247.73.60... >>>>>>>>> >>>>>>>>> * Connected to l2se0060.lss.emc.com (10.247.73.60) port 8443 (#0) >>>>>>>>> >>>>>>>>> * successfully set certificate verify locations: >>>>>>>>> >>>>>>>>> * CAfile: /usr/yhuang/cert.pem >>>>>>>>> >>>>>>>>> CApath: none >>>>>>>>> >>>>>>>>> * error:0506706E:Diffie-Hellman routines:GENERATE_KEY:key size too >>>>>>>>> small >>>>>>>>> >>>>>>>>> * Closing connection 0 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> [root@l2se0132 bin]# more /debug.txt >>>>>>>>> >>>>>>>>> * About to connect() to l2se0060.lss.emc.com port 8443 (#0) >>>>>>>>> >>>>>>>>> * Trying 10.247.73.60... >>>>>>>>> >>>>>>>>> * Connected to l2se0060.lss.emc.com (10.247.73.60) port 8443 (#0) >>>>>>>>> >>>>>>>>> * error:0506706E:Diffie-Hellman routines:GENERATE_KEY:key size too >>>>>>>>> small >>>>>>>>> >>>>>>>>> * Closing connection 0 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, Mar 15, 2013 at 3:45 AM, Daniel Stenberg >>>>>>>>> <[email protected]>wrote: >>>>>>>>> >>>>>>>>>> On Thu, 14 Mar 2013, cnm marketing wrote: >>>>>>>>>> >>>>>>>>>> * error:0506706E:Diffie-Hellman routines:GENERATE_KEY:key size >>>>>>>>>>> too small >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Please stop top-posting and full-quoting. >>>>>>>>>> >>>>>>>>>> My 3.2 seconds of googling on this topic lead to this: >>>>>>>>>> >>>>>>>>>> http://comments.gmane.org/**gmane.comp.encryption.openssl.** >>>>>>>>>> user/43777<http://comments.gmane.org/gmane.comp.encryption.openssl.user/43777> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> >>>>>>>>>> / daniel.haxx.se >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
