You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by jean-frederic clere <jf...@gmail.com> on 2015/12/14 14:12:52 UTC
Weird behaviour with mod_ssl and SSLCryptoDevice
Hi,
I am sure I am doing something wrong, but when using a dummy crypto
device to recreate a customer issue I am getting a similar issue in
httpd-trunk but I am nearly sure someone would have complained here if
that would be the case.
Comments
Jean-Frederic
The stack:
+++
(gdb) bt
#0 0x00007fac11198a98 in raise () from /lib64/libc.so.6
#1 0x00007fac1119a69a in abort () from /lib64/libc.so.6
#2 0x00007fac01f27e33 in dummy_init (e=<optimized out>) at e_dummy.c:146
#3 0x00007fac05a69509 in test_rc4_init_key () from /lib64/libcrypto.so.10
#4 0x00007fac05b3374c in ?? () from /lib64/libcrypto.so.10
#5 0x00007fac00000001 in ?? ()
#6 0x0000000000e37138 in ?? ()
#7 0x0000000000e62348 in ?? ()
#8 0x00007fac11d9d68a in apr_pool_cleanup_register (p=0x7fac05a6a122
<dynamic_ctrl+210>, data=0xfe4678, plain_cleanup_fn=0x1,
child_cleanup_fn=0x7fac05dab5c0)
at memory/unix/apr_pools.c:2218
#9 0x0000000000f094c0 in ?? ()
#10 0x00007fac0625bf60 in ?? () from /home/jfclere/APACHE/modules/mod_ssl.so
#11 0x0000000000e60938 in ?? ()
#12 0x0000000000e62348 in ?? ()
#13 0x00007fac05a6ac58 in BUF_memdup () from /lib64/libcrypto.so.10
#14 0x00007fac06039af2 in ssl_init_Engine (s=0xe60938,
s@entry=0x7fffb9ad2e90, p=p@entry=0xe37138) at ssl_engine_init.c:386
#15 0x00007fac0603bdaf in ssl_init_Module (p=0xe37138, plog=<optimized
out>, ptemp=0xf09780, base_server=0x7fffb9ad2e90) at ssl_engine_init.c:242
#16 0x0000000000455153 in ap_run_post_config
(pconf=pconf@entry=0xe37138, plog=0xea0778, ptemp=0xe62348, s=0xe60938)
at config.c:103
#17 0x000000000042c575 in main (argc=3, argv=0x7fffb9ad3158) at main.c:788
+++
Re: Weird behaviour with mod_ssl and SSLCryptoDevice
Posted by jean-frederic clere <jf...@gmail.com>.
On 12/14/2015 02:12 PM, jean-frederic clere wrote:
> Hi,
>
> I am sure I am doing something wrong, but when using a dummy crypto
> device to recreate a customer issue I am getting a similar issue in
> httpd-trunk but I am nearly sure someone would have complained here if
> that would be the case.
Note when I add a 1024 DH parameter to the certificate I don't get a
core but when using a 2048 I do get a core.
Cheers
Jean-Frederic
>
> Comments
>
> Jean-Frederic
>
> The stack:
> +++
> (gdb) bt
> #0 0x00007fac11198a98 in raise () from /lib64/libc.so.6
> #1 0x00007fac1119a69a in abort () from /lib64/libc.so.6
> #2 0x00007fac01f27e33 in dummy_init (e=<optimized out>) at e_dummy.c:146
> #3 0x00007fac05a69509 in test_rc4_init_key () from /lib64/libcrypto.so.10
> #4 0x00007fac05b3374c in ?? () from /lib64/libcrypto.so.10
> #5 0x00007fac00000001 in ?? ()
> #6 0x0000000000e37138 in ?? ()
> #7 0x0000000000e62348 in ?? ()
> #8 0x00007fac11d9d68a in apr_pool_cleanup_register (p=0x7fac05a6a122
> <dynamic_ctrl+210>, data=0xfe4678, plain_cleanup_fn=0x1,
> child_cleanup_fn=0x7fac05dab5c0)
> at memory/unix/apr_pools.c:2218
> #9 0x0000000000f094c0 in ?? ()
> #10 0x00007fac0625bf60 in ?? () from /home/jfclere/APACHE/modules/mod_ssl.so
> #11 0x0000000000e60938 in ?? ()
> #12 0x0000000000e62348 in ?? ()
> #13 0x00007fac05a6ac58 in BUF_memdup () from /lib64/libcrypto.so.10
> #14 0x00007fac06039af2 in ssl_init_Engine (s=0xe60938,
> s@entry=0x7fffb9ad2e90, p=p@entry=0xe37138) at ssl_engine_init.c:386
> #15 0x00007fac0603bdaf in ssl_init_Module (p=0xe37138, plog=<optimized
> out>, ptemp=0xf09780, base_server=0x7fffb9ad2e90) at ssl_engine_init.c:242
> #16 0x0000000000455153 in ap_run_post_config
> (pconf=pconf@entry=0xe37138, plog=0xea0778, ptemp=0xe62348, s=0xe60938)
> at config.c:103
> #17 0x000000000042c575 in main (argc=3, argv=0x7fffb9ad3158) at main.c:788
> +++
>
Re: Weird behaviour with mod_ssl and SSLCryptoDevice
Posted by jean-frederic clere <jf...@gmail.com>.
On 12/14/2015 02:18 PM, Stefan Eissing wrote:
> You're certain it's only loaded once?
I think the issue is that it is loaded twice :-(
Cheers
Jean-Frederic
>
>> Am 14.12.2015 um 14:12 schrieb jean-frederic clere <jf...@gmail.com>:
>>
>> <e_dummy.c>
>
>
Re: Weird behaviour with mod_ssl and SSLCryptoDevice
Posted by Stefan Eissing <st...@greenbytes.de>.
You're certain it's only loaded once?
> Am 14.12.2015 um 14:12 schrieb jean-frederic clere <jf...@gmail.com>:
>
> <e_dummy.c>
Re: Weird behaviour with mod_ssl and SSLCryptoDevice
Posted by jean-frederic clere <jf...@gmail.com>.
On 01/06/2016 01:17 PM, Yann Ylavic wrote:
> On Wed, Jan 6, 2016 at 12:28 PM, jean-frederic clere <jf...@gmail.com> wrote:
>> On 12/15/2015 03:16 PM, Jan Kaluža wrote:
>>> On 12/15/2015 02:16 PM, Yann Ylavic wrote:
>>>> Hi Jan,
>>>>
>>>> On Tue, Dec 15, 2015 at 12:51 PM, Jan Kaluža <jk...@redhat.com> wrote:
>>>>>
>>>>> I think I've just fixed that in <http://svn.apache.org/r1720129>. I will
>>>>> also propose that for 2.4.x and 2.2.x.
>>>>
>>>> Shouldn't we do the same for ecparams below?
>>>
>>> Probably yes, I was just checking the arguments which get passed to
>>> "SSL_CTX_set_*" functions. I think you are right we should call
>>> EC_GROUP_free there.
>>
>> According to my tests with trunk there is still a problem, the
>> ENGINE_cleanup() doesn't finish the engines, I have tried to use
>> CRYPTO_mem_leaks_fp() to find the leak but there are too many of them to
>> find where we miss a "free()".
>>
>> Any idea on the topic?
>
> I just committed (r1723295) a fix for the leak mentioned above.
It doesn't help :-(
> Do you also use some custom ecparams in the certificate file?
No the core also happens without any parameter in the certificate file.
Cheers
Jean-Frederic
Re: Weird behaviour with mod_ssl and SSLCryptoDevice
Posted by Yann Ylavic <yl...@gmail.com>.
On Wed, Jan 6, 2016 at 12:28 PM, jean-frederic clere <jf...@gmail.com> wrote:
> On 12/15/2015 03:16 PM, Jan Kaluža wrote:
>> On 12/15/2015 02:16 PM, Yann Ylavic wrote:
>>> Hi Jan,
>>>
>>> On Tue, Dec 15, 2015 at 12:51 PM, Jan Kaluža <jk...@redhat.com> wrote:
>>>>
>>>> I think I've just fixed that in <http://svn.apache.org/r1720129>. I will
>>>> also propose that for 2.4.x and 2.2.x.
>>>
>>> Shouldn't we do the same for ecparams below?
>>
>> Probably yes, I was just checking the arguments which get passed to
>> "SSL_CTX_set_*" functions. I think you are right we should call
>> EC_GROUP_free there.
>
> According to my tests with trunk there is still a problem, the
> ENGINE_cleanup() doesn't finish the engines, I have tried to use
> CRYPTO_mem_leaks_fp() to find the leak but there are too many of them to
> find where we miss a "free()".
>
> Any idea on the topic?
I just committed (r1723295) a fix for the leak mentioned above.
Do you also use some custom ecparams in the certificate file?
Regards,
Yann.
Re: Weird behaviour with mod_ssl and SSLCryptoDevice
Posted by jean-frederic clere <jf...@gmail.com>.
On 12/15/2015 03:16 PM, Jan Kaluža wrote:
> On 12/15/2015 02:16 PM, Yann Ylavic wrote:
>> Hi Jan,
>>
>> On Tue, Dec 15, 2015 at 12:51 PM, Jan Kaluža <jk...@redhat.com> wrote:
>>>
>>> I think I've just fixed that in <http://svn.apache.org/r1720129>. I will
>>> also propose that for 2.4.x and 2.2.x.
>>
>> Shouldn't we do the same for ecparams below?
>
> Probably yes, I was just checking the arguments which get passed to
> "SSL_CTX_set_*" functions. I think you are right we should call
> EC_GROUP_free there.
According to my tests with trunk there is still a problem, the
ENGINE_cleanup() doesn't finish the engines, I have tried to use
CRYPTO_mem_leaks_fp() to find the leak but there are too many of them to
find where we miss a "free()".
Any idea on the topic?
Cheers
Jean-Frederic
Re: Weird behaviour with mod_ssl and SSLCryptoDevice
Posted by Jan Kaluža <jk...@redhat.com>.
On 12/15/2015 02:16 PM, Yann Ylavic wrote:
> Hi Jan,
>
> On Tue, Dec 15, 2015 at 12:51 PM, Jan Kaluža <jk...@redhat.com> wrote:
>>
>> I think I've just fixed that in <http://svn.apache.org/r1720129>. I will
>> also propose that for 2.4.x and 2.2.x.
>
> Shouldn't we do the same for ecparams below?
Probably yes, I was just checking the arguments which get passed to
"SSL_CTX_set_*" functions. I think you are right we should call
EC_GROUP_free there.
Jan Kaluza
> Regards,
> Yann.
>
Re: Weird behaviour with mod_ssl and SSLCryptoDevice
Posted by Yann Ylavic <yl...@gmail.com>.
Hi Jan,
On Tue, Dec 15, 2015 at 12:51 PM, Jan Kaluža <jk...@redhat.com> wrote:
>
> I think I've just fixed that in <http://svn.apache.org/r1720129>. I will
> also propose that for 2.4.x and 2.2.x.
Shouldn't we do the same for ecparams below?
Regards,
Yann.
Re: Weird behaviour with mod_ssl and SSLCryptoDevice
Posted by Jan Kaluža <jk...@redhat.com>.
On 12/14/2015 02:12 PM, jean-frederic clere wrote:
> Hi,
>
> I am sure I am doing something wrong, but when using a dummy crypto
> device to recreate a customer issue I am getting a similar issue in
> httpd-trunk but I am nearly sure someone would have complained here if
> that would be the case.
Hi,
I think I've just fixed that in <http://svn.apache.org/r1720129>. I will
also propose that for 2.4.x and 2.2.x.
Regards,
Jan Kaluza
> Comments
>
> Jean-Frederic
>
> The stack:
> +++
> (gdb) bt
> #0 0x00007fac11198a98 in raise () from /lib64/libc.so.6
> #1 0x00007fac1119a69a in abort () from /lib64/libc.so.6
> #2 0x00007fac01f27e33 in dummy_init (e=<optimized out>) at e_dummy.c:146
> #3 0x00007fac05a69509 in test_rc4_init_key () from /lib64/libcrypto.so.10
> #4 0x00007fac05b3374c in ?? () from /lib64/libcrypto.so.10
> #5 0x00007fac00000001 in ?? ()
> #6 0x0000000000e37138 in ?? ()
> #7 0x0000000000e62348 in ?? ()
> #8 0x00007fac11d9d68a in apr_pool_cleanup_register (p=0x7fac05a6a122
> <dynamic_ctrl+210>, data=0xfe4678, plain_cleanup_fn=0x1,
> child_cleanup_fn=0x7fac05dab5c0)
> at memory/unix/apr_pools.c:2218
> #9 0x0000000000f094c0 in ?? ()
> #10 0x00007fac0625bf60 in ?? () from /home/jfclere/APACHE/modules/mod_ssl.so
> #11 0x0000000000e60938 in ?? ()
> #12 0x0000000000e62348 in ?? ()
> #13 0x00007fac05a6ac58 in BUF_memdup () from /lib64/libcrypto.so.10
> #14 0x00007fac06039af2 in ssl_init_Engine (s=0xe60938,
> s@entry=0x7fffb9ad2e90, p=p@entry=0xe37138) at ssl_engine_init.c:386
> #15 0x00007fac0603bdaf in ssl_init_Module (p=0xe37138, plog=<optimized
> out>, ptemp=0xf09780, base_server=0x7fffb9ad2e90) at ssl_engine_init.c:242
> #16 0x0000000000455153 in ap_run_post_config
> (pconf=pconf@entry=0xe37138, plog=0xea0778, ptemp=0xe62348, s=0xe60938)
> at config.c:103
> #17 0x000000000042c575 in main (argc=3, argv=0x7fffb9ad3158) at main.c:788
> +++
>