Re: Weird behaviour with mod_ssl and SSLCryptoDevice

[jean-frederic clere]

On 01/06/2016 01:17 PM, Yann Ylavic wrote:
> On Wed, Jan 6, 2016 at 12:28 PM, jean-frederic clere  
> 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  wrote:
>
> I think I've just fixed that in . 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

[Yann Ylavic]

On Wed, Jan 6, 2016 at 12:28 PM, jean-frederic clere  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  wrote:

 I think I've just fixed that in . 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

[jean-frederic clere]

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  wrote:
>>>
>>> I think I've just fixed that in . 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

[Jan Kaluža]

On 12/15/2015 02:16 PM, Yann Ylavic wrote:

Hi Jan,

On Tue, Dec 15, 2015 at 12:51 PM, Jan Kaluža  wrote:


I think I've just fixed that in . 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

[Yann Ylavic]

Hi Jan,

On Tue, Dec 15, 2015 at 12:51 PM, Jan Kaluža  wrote:
>
> I think I've just fixed that in . 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

[Jan Kaluža]

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 . I will 
also propose that for 2.4.x and 2.2.x.


Regards,
Jan Kaluza


Comments

Jean-Frederic

The stack:
+++
(gdb) bt
#0  0x7fac11198a98 in raise () from /lib64/libc.so.6
#1  0x7fac1119a69a in abort () from /lib64/libc.so.6
#2  0x7fac01f27e33 in dummy_init (e=) at e_dummy.c:146
#3  0x7fac05a69509 in test_rc4_init_key () from /lib64/libcrypto.so.10
#4  0x7fac05b3374c in ?? () from /lib64/libcrypto.so.10
#5  0x7fac0001 in ?? ()
#6  0x00e37138 in ?? ()
#7  0x00e62348 in ?? ()
#8  0x7fac11d9d68a in apr_pool_cleanup_register (p=0x7fac05a6a122
, data=0xfe4678, plain_cleanup_fn=0x1,
child_cleanup_fn=0x7fac05dab5c0)
 at memory/unix/apr_pools.c:2218
#9  0x00f094c0 in ?? ()
#10 0x7fac0625bf60 in ?? () from /home/jfclere/APACHE/modules/mod_ssl.so
#11 0x00e60938 in ?? ()
#12 0x00e62348 in ?? ()
#13 0x7fac05a6ac58 in BUF_memdup () from /lib64/libcrypto.so.10
#14 0x7fac06039af2 in ssl_init_Engine (s=0xe60938,
s@entry=0x7fffb9ad2e90, p=p@entry=0xe37138) at ssl_engine_init.c:386
#15 0x7fac0603bdaf in ssl_init_Module (p=0xe37138, plog=, ptemp=0xf09780, base_server=0x7fffb9ad2e90) at ssl_engine_init.c:242
#16 0x00455153 in ap_run_post_config
(pconf=pconf@entry=0xe37138, plog=0xea0778, ptemp=0xe62348, s=0xe60938)
at config.c:103
#17 0x0042c575 in main (argc=3, argv=0x7fffb9ad3158) at main.c:788
+++

Re: Weird behaviour with mod_ssl and SSLCryptoDevice

[jean-frederic clere]

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

Re: Weird behaviour with mod_ssl and SSLCryptoDevice

[jean-frederic clere]

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  0x7fac11198a98 in raise () from /lib64/libc.so.6
> #1  0x7fac1119a69a in abort () from /lib64/libc.so.6
> #2  0x7fac01f27e33 in dummy_init (e=) at e_dummy.c:146
> #3  0x7fac05a69509 in test_rc4_init_key () from /lib64/libcrypto.so.10
> #4  0x7fac05b3374c in ?? () from /lib64/libcrypto.so.10
> #5  0x7fac0001 in ?? ()
> #6  0x00e37138 in ?? ()
> #7  0x00e62348 in ?? ()
> #8  0x7fac11d9d68a in apr_pool_cleanup_register (p=0x7fac05a6a122
> , data=0xfe4678, plain_cleanup_fn=0x1,
> child_cleanup_fn=0x7fac05dab5c0)
> at memory/unix/apr_pools.c:2218
> #9  0x00f094c0 in ?? ()
> #10 0x7fac0625bf60 in ?? () from /home/jfclere/APACHE/modules/mod_ssl.so
> #11 0x00e60938 in ?? ()
> #12 0x00e62348 in ?? ()
> #13 0x7fac05a6ac58 in BUF_memdup () from /lib64/libcrypto.so.10
> #14 0x7fac06039af2 in ssl_init_Engine (s=0xe60938,
> s@entry=0x7fffb9ad2e90, p=p@entry=0xe37138) at ssl_engine_init.c:386
> #15 0x7fac0603bdaf in ssl_init_Module (p=0xe37138, plog= out>, ptemp=0xf09780, base_server=0x7fffb9ad2e90) at ssl_engine_init.c:242
> #16 0x00455153 in ap_run_post_config
> (pconf=pconf@entry=0xe37138, plog=0xea0778, ptemp=0xe62348, s=0xe60938)
> at config.c:103
> #17 0x0042c575 in main (argc=3, argv=0x7fffb9ad3158) at main.c:788
> +++
> 

Re: Weird behaviour with mod_ssl and SSLCryptoDevice

[Stefan Eissing]

You're certain it's only loaded once?

> Am 14.12.2015 um 14:12 schrieb jean-frederic clere :
> 
>