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 <cnn.marketing_at_gmail.com>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 <cnn.marketing_at_gmail.com>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 <cnn.marketing_at_gmail.com>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 <cnn.marketing_at_gmail.com>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 <
>>>> cnn.marketing_at_gmail.com> 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 <
>>>>> cnn.marketing_at_gmail.com> 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 <
>>>>>> cnn.marketing_at_gmail.com> 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 <
>>>>>>> cnn.marketing_at_gmail.com> 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 <
>>>>>>>> cnn.marketing_at_gmail.com> 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_at_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_at_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 <daniel_at_haxx.se>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
Received on 2013-03-22