On 16-03-13 22:16, cnm marketing wrote:
> We'll try your way and Yang's way to debug and see what the data looks
> like in the openssl layer.

Yes, a bottom up debugging approach might give the insight you need
here. But... I'm trying to understand your problem in your
application... and I feel this part of the debugging is WAAAY beyond the
scope of this mail list. Especially when you mention a normal curl
execution just works.

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

The Diffie-Hellman key exchange doesn't always mean the certificate
file. It is an additional stage in the SSL handshake. If you use a
specific DH-key, we wish to see what's in there. If you don't have one,
perhaps there is somewhere else on the system one or it's generated
dynamically.

The problem is... we are walking in the blind here as you didn't
disclose what your setup looks like and what input for SSL you have and use.

If you don't know what this means, you are likely just using DH with
dynamic key generation. I started looking up the code in OpenSSL and you
can't really influence the size. Well, you can, at compile time for the
most part of OpenSSL.

> 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??!

Yes, library loading can be a magical experience... :-)

If you run the system supplied curl and you didn't change library
loading stuff, you'll probably use the system OpenSSL libraries.

But... I have no idea what you are doing in your application with
already loaded OpenSSL. If the dynamic loader discovers you needed
OpenSSL for libcurl and it's already satisfied by a previously loaded
OpenSSL, it will skip loading the default OpenSSL from the system for
libcurl and +1 the reference counter on the already loaded openssl library.

Again... this piece of the puzzle is part of your application. I hope
you can try to uncover this with the previously mentioned methods to
chart the library loading at initial run-time and then you can start by
charting the second dimension when you used dlopen/dlsym/dlclose.

        Oscar "loves a mystery without the burns"

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html