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-17