Re: [openssl.org #1949] mod_ssl/openssl failures when more than 85 CAs are configured

2010-01-24 Thread Maarten Litmaath via RT
Hi Steve,

>>> Do you also agree with David's proposal to change the calls to
>>> BIO_ctrl(, BIO_CTRL_INFO, ) into BIO_wpending() in ssl/*.c?  It seems
>>> to
>>> make sense to me.
>>>
>>
>> Yes, I've applied it to all branches now. Many thanks David. Ticket
>> resolved.
>>
>
> Just a postscript to the issue. The above minimal fix was applied to
> OpenSSL but the lack of a corresponding Apache fix has resulted in some
> problems, not least of which is renegotiation not working because the
> server hello request is not flushed.
>
> As a result the OpenSSL change has been updated to call BIO_CTRL_INFO
> and if that returns zero BIO_CTRL_WPENDING. This should now cover all cases.

Thanks for that fix and for informing us.


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: [openssl.org #1949] mod_ssl/openssl failures when more than 85 CAs are configured

2009-06-15 Thread Maarten Litmaath via RT
Hi Roumen,

> >  > it hangs the same , remove a few cas and it works.
> >  >
> >  > # rpm -q httpd mod_ssl openssl fedora-release
> >  > httpd-2.2.11-8.x86_64
> >  > mod_ssl-2.2.11-8.x86_64
> >  > openssl-0.9.8k-4.fc11.x86_64
> >  > fedora-release-11-1.noarch
> [...]
> 
> May be problem is in 64-bit OpenSSL (fedora?) build ?

We see the same problem on 32-bit architectures.


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: [openssl.org #1949] mod_ssl/openssl failures when more than 85 CAs are configured

2009-06-15 Thread Maarten Litmaath via RT
Hi Stephen,

> I can't see how anything could cause an issue with 85 CAs. The attached
> descriptions imply it might be a mod_ssl issue (not reproducible with
> s_server).

There is a bit more information now in our ticket:

 https://savannah.cern.ch/bugs/?48458

Romain Wartel wrote:

 > So 4 conditions need to be met to reproduce the bug:
 > - More than ~85 root CAs installed (the exact number varies)
 > - The host certificate has been issued by the CERN CA
 > - OpenSSL is configured to check the client side certificate
 >   (optional or required)
 > - Both the CERN-Root CA and the CERN-TCA CA have to be installed

However, Lassi A. Tuura then wrote:

 > There is only one known condition triggering the problem,
 > as quoted earlier in this thread: SSL re-negotiation response >= 12kB
 > leads to failure to flush the data to socket leading to server and
 > client to wait indefinitely for each other.
 >
 > There's any number of ways to trim or expand the SSL response size
 > to cross that threshold.

The CERN CA has the second biggest size of all ~90 CAs currently
supported by IGTF, which might explain why only CERN services are
affected at this time.  OTOH, it does not look very different from
others in the top 10:

1e12d831.0 2594
1d879c6c.0 2204
9ff26ea4.0 2143
55994d72.0 2029
9dd23746.0 1996
0a2bac92.0 1976
f5ead794.0 1919
03aa0ecb.0 1907
6fee79b0.0 1903
fe102e03.0 1900

Then again, we may need to add the size of the CERN _Root_ CA:

d254cc30.0 1350

But there are other such chained CAs that do not cause problems...

> I'd suggest trying OpenSSL 0.9.8k as well though because some code
> changes might have an effect in that area.

Steve Traylen wrote:

 > it hangs the same , remove a few cas and it works.
 >
 > # rpm -q httpd mod_ssl openssl fedora-release
 > httpd-2.2.11-8.x86_64
 > mod_ssl-2.2.11-8.x86_64
 > openssl-0.9.8k-4.fc11.x86_64
 > fedora-release-11-1.noarch

Might it be worth trying 1.0.0 as well?
Thanks,
Maarten


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


[openssl.org #1949] mod_ssl/openssl failures when more than 85 CAs are configured

2009-06-04 Thread Maarten Litmaath via RT
Dear OpenSSL developers,
please have a look at the following bug about a bad interaction
between mod_ssl and openssl 0.9.7, 0.9.8 and possibly higher
versions when the server side supports more than 85 CAs:

 https://issues.apache.org/bugzilla/show_bug.cgi?id=46952

So far this has only caused problems for services whose certs
were issued by the CERN CA, a standard Microsoft CA instance.

The mod_ssl developer who responded thinks this might be a bug
in openssl rather than mod_ssl: can you comment?

This issue is steadily moving toward becoming a big nuisance
for CERN and the projects it participates in, e.g. EGEE.

For completeness, our problem is documented here:

 https://savannah.cern.ch/bugs/?48458

Thanks,
Maarten

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: [openssl.org #1778] default maximum chain length considered too low

2008-11-10 Thread Maarten Litmaath via RT
Hi Stephen,

> > [EMAIL PROTECTED] - Thu Nov 06 09:19:52 2008]:
> > 
> > Why not increase the default, say, to 100 instead, as Globus did?
> > 
> > 
> 
> What did they actually change?
> 
> Changing the line:
> 
> 9,  /* depth */
> 
> in x509_vpm.c should do the trick. Can you confirm this works?

Globus calls SSL_CTX_set_verify_depth() with a value of 100:

http://viewcvs.globus.org/viewcvs.cgi/gsi/callback/source/library/globus_gsi_callback_constants.h?r1=1.7&r2=1.8

So, if that call exactly overrides the value 9 in x509_vpm.c,
then setting it to 100 would be equivalent to the Globus fix.

I hope the hardcoded depth does not appear in more places?
Thanks,
Maarten


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]


[openssl.org #1778] default maximum chain length considered too low

2008-11-06 Thread Maarten Litmaath via RT
Dear OpenSSL developers,
on August 14 I posted this matter to the developer list.  There has
been no response.  Please include this issue in the bug tracker.

Various grid projects have run into the default maximum chain length
of 9 being too low.  These bug reports show examples:

http://bugzilla.globus.org/globus/show_bug.cgi?id=4994

https://savannah.cern.ch/bugs/index.php?37563

The functions SSL_CTX_set_verify_depth() and SSL_set_verify_depth()
allow the maximum length to be increased, but this means that every
application or library around OpenSSL needs to make such calls.
Why not increase the default, say, to 100 instead, as Globus did?
Thanks,
Maarten (CERN/LCG/EGEE)

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]