Thanks Jeff.

I'll ask Sep to get a stack trace with the newer version. He said he tried it on HEAD and had the same issue, but he didn't have a copy of the stack trace.

What happens if you disable Diffie-Hellman?


Jade Rubick
Director of Development
120 Wall Street, 4th Floor
New York, NY 10005 USA
+1 503 285 4963
+1 707 671 1333 fax

The information contained in this email/document is confidential and may be legally privileged. Access to this email/document by anyone other than the intended recipient(s) is unauthorized. If you are not an intended recipient, any disclosure, copying, distribution, or any action taken or omitted to be taken in reliance to it, is prohibited.

On Apr 23, 2009, at 6:58 PM, Jeff Hobbs wrote:

Hi Jade,

Sorry about the delayed response, I was on vacation the last couple of weeks.

Your code line is not consistent with tls 1.6. I would recommend trying the latest release first, which has a few mem leak and cleanup issues noted.


On 14/04/2009 10:11 AM, Jade Rubick wrote:
We noticed that whenever we made web services calls (using tsoap) over https, Aolserver was crashing with a signal 11 (IIRC). We did a fair amount of debugging, and wanted to ask for some help with the rest. After turning debugging on, one of my team members here (Sep) produced this trace and analysis. Can anyone help us track down if we've discovered a bug, and if it is safe to disable Diffie-Hellman?
Program received signal SIGABRT, Aborted.
[Switching to Thread -1448084592 (LWP 11092)]
0xffffe410 in __kernel_vsyscall ()
(gdb) bt
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7c68875 in raise () from /lib/tls/i686/cmov/
#2  0xb7c6a201 in abort () from /lib/tls/i686/cmov/
#3  0xb7e7aa4f in Tcl_PanicVA () from /usr/local/tcl/lib/
#4  0xb7e7aa77 in Tcl_Panic () from /usr/local/tcl/lib/
#5  0xb7e89b4f in Ptr2Block () from /usr/local/tcl/lib/
#6  0xb7e8a117 in TclpFree () from /usr/local/tcl/lib/
#7  0xb7e2a51d in Tcl_Free () from /usr/local/tcl/lib/
#8 0xb7eba251 in ns_free () from /usr/local/aolserver40r10/lib/ #9 0xb5ff14aa in CRYPTO_free () from /usr/lib/i686/cmov/ #10 0xb601e0aa in BN_clear_free () from /usr/lib/i686/cmov/ #11 0xb6045836 in DH_free () from /usr/lib/i686/cmov/ 0.9.8 *#12 0xa9910e51 in CTX_Init (statePtr=0x168b7e38, proto=3, key=0x0, cert=0x0,*
*    CAdir=0x0, CAfile=0x0, ciphers=0x0) at tls.c:961*
#13 0xa991084f in ImportObjCmd (clientData=0x0, interp=0x13066570, objc=4,
   objv=0xa9afb6bc) at tls.c:801
#14 0xb7e253c3 in TclEvalObjvInternal () from /usr/local/tcl/lib/
#61 0xb7e25987 in Tcl_EvalEx () from /usr/local/tcl/lib/
#62 0xb7e25c8c in Tcl_Eval () from /usr/local/tcl/lib/
#63 0xb7e25d26 in Tcl_GlobalEval () from /usr/local/tcl/lib/ #64 0xb7efbe83 in ProcRequest () from /usr/local/aolserver40r10/lib/
#65 0xb7ee823b in Ns_ConnRunRequest ()
  from /usr/local/aolserver40r10/lib/
#66 0xb7ee99fc in NsConnThread () from /usr/local/aolserver40r10/ lib/
#67 0xb7ebb48f in NsThreadMain ()
  from /usr/local/aolserver40r10/lib/
#68 0xb7ebcb6d in ThreadMain ()
  from /usr/local/aolserver40r10/lib/
#69 0xb7dd346b in start_thread () from /lib/tls/i686/cmov/
#70 0xb7d116de in clone () from /lib/tls/i686/cmov/
That line is:
961             DH_free(dh);
This is the 12th level of the running stack and it's a reference to DH_free in line 961 in the tls package. I am not certain if this is the source of all our woes, however, I inspected the code a bit and it looks like some programmatic error (though it is a wonder how this is included in multiple releases of tls, I would suggest talking with the tls mailing list about this... for more information. I'm eager to find out what and why it causes the crash)
Here's the code at tls.c:
#ifndef NO_DH
       DH* dh = get_dh512();
       SSL_CTX_set_tmp_dh(ctx, dh);
The entire code is, interestingly, wrapped around the NO_DH if- check, this reads "If NO_DH variable is not define, do the following". And so the crash happens when the dh pointer is being freed. What is interesting to point out is that get_dh512() is defined as:
*static* DH *get_dh512()
I'm not sure how and what the purpose is, but the way I see this is that the pointer returned is a static DH pointer and we know how freeing static pointers go. I rebuilt the tls-head (tls1.5.1) package except I disabled the DH routines. I inserted this on tls.c, line 75:
#define NO_DH 1
This will toggle tls not to use DH which is part of the libcrypto library. Now, I'm not sure if my change here effectively disabled ssh, but it seems to have extracted the soap-response just fine. Like I said, the ramifications of this change needs the expertise of the TLS folks.
Either way, this is certainly one way of going about this.
According to SSL, dh is the Diffie-Hellman key agreement
More info:
After some reading, I'm half-convinced this should not shut down ssl encryption of packets. The other half is up in the air.
Is this a bug in TLS and/or its interaction with Aolserver? And is it safe to disable Diffie-Hellman?

AOLserver -

To Remove yourself from this list, simply send an email to 
<> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: 
field of your email blank.

Reply via email to