Re: [openssl.org #1949] mod_ssl/openssl failures when more than 85 CAs are configured
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
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
Re: [openssl.org #1949] mod_ssl/openssl failures when more than 85 CAs are configured
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
[openssl.org #1949] mod_ssl/openssl failures when more than 85 CAs are configured
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
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.7r2=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
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]
