Re: Strange error(parse tlsext bug) in mod_ssl since httpd-2.2.12
Hi Kaspar, I applied your 'mod_ssl-disable_tls_tickets.diff' and 'mod_ssl-log_ssloptions.diff' to apache-2.2.12 and initiated the 'failing svn import operation'. snip from error_log while this fails [Mon Oct 26 15:48:21 2009] [warn] [client 10.2.0.88] ssl_init_ssl_connection: options=0x1114fff [Mon Oct 26 15:48:22 2009] [warn] [client 10.2.0.88] ssl_init_ssl_connection: options=0x1114fff [Mon Oct 26 15:48:22 2009] [warn] [client 10.2.0.88] ssl_init_ssl_connection: options=0x1114fff /snip The tcpdump for this failure is at, http://www.livecipher.com/tlsext_dump/tlsext.dmp.4 With regards Kamesh Jayachandran On 10/25/2009 09:21 PM, Kaspar Brand wrote: Dr Stephen Henson wrote: Disabling tickets using SSL_OP_NO_TICKET server side SHOULD work too (does in my tests) so I've no idea why that wouldn't in the OPs setup unless the patch doesn't set it in all contexts. Try placing it right after any call to SSL_CTX_new(). I'm still a bit puzzled as to why my previously posted patch does not turn off TLS session tickets... there's only one place in mod_ssl where a new context is created, and in my tests, SSL_OP_NO_TICKET was reliably applied (i.e., I didn't see any session tickets on the wire). Maybe there's another issue if tickets are turned off? Kamesh, could you apply the attached patch, for diagnostic purposes (in addition to mod_ssl-disable_tls_tickets.diff), and let us know what options= values you see in your ErrorLog? Note that you don't have to increase Apache's LogLevel, the options for any new SSL connection will be logged with warn already. Also, it would be helpful to have another capture (with mod_ssl patched like this) where the svn client still fails with a parse tlsext error. Thanks. Kaspar
Re: mod_fcgid creates 1 more process then allowed
Jeff Trawick wrote: On Wed, Oct 21, 2009 at 6:53 AM, Barry Scott barry.sc...@onelan.co.uk wrote: I have configure with a limit of 16 processes but have 17 running and logs claiming 16 running. You should probably open a bug report for this. That's not to say that others haven't started thinking about it, but I haven't seen any activity. I wonder if a process is stuck in the error list or somewhere else... I think that it would be very cool to have a status handler to get the PM to report the contents of the several lists, and format appropriately ;) Filed: https://issues.apache.org/bugzilla/show_bug.cgi?id=48057 Barry
Re: svn commit: r829619 - in /httpd/httpd/trunk: ./ modules/ssl/
jor...@apache.org writes:
Author: jorton
Date: Sun Oct 25 17:21:10 2009
New Revision: 829619
...
+const char *ssl_cmd_SSLStaplingResponseTimeSkew(cmd_parms *cmd, void *dcfg,
+const char *arg)
+{
+SSLSrvConfigRec *sc = mySrvConfig(cmd-server);
+sc-server-stapling_resptime_skew = atoi(arg);
+if (sc-server-stapling_resptime_skew 0) {
+return SSLstapling_resptime_skew: invalid argument;
+}
+return NULL;
+}
+
+const char *ssl_cmd_SSLStaplingResponseMaxAge(cmd_parms *cmd, void *dcfg,
+const char *arg)
+{
+SSLSrvConfigRec *sc = mySrvConfig(cmd-server);
+sc-server-stapling_resp_maxage = atoi(arg);
+if (sc-server-stapling_resp_maxage 0) {
+return SSLstapling_resp_maxage: invalid argument;
+}
+return NULL;
+}
+
+const char *ssl_cmd_SSLStaplingStandardCacheTimeout(cmd_parms *cmd, void
*dcfg,
+const char *arg)
+{
+SSLSrvConfigRec *sc = mySrvConfig(cmd-server);
+sc-server-stapling_cache_timeout = atoi(arg);
+if (sc-server-stapling_cache_timeout 0) {
+return SSLstapling_cache_timeout: invalid argument;
+}
+return NULL;
+}
+
+const char *ssl_cmd_SSLStaplingErrorCacheTimeout(cmd_parms *cmd, void *dcfg,
+ const char *arg)
+{
+SSLSrvConfigRec *sc = mySrvConfig(cmd-server);
+sc-server-stapling_errcache_timeout = atoi(arg);
+if (sc-server-stapling_errcache_timeout 0) {
+return SSLstapling_errcache_timeout: invalid argument;
+}
+return NULL;
+}
...
+const char *ssl_cmd_SSLStaplingResponderTimeout(cmd_parms *cmd, void *dcfg,
+const char *arg)
+{
+SSLSrvConfigRec *sc = mySrvConfig(cmd-server);
+sc-server-stapling_responder_timeout = atoi(arg);
+sc-server-stapling_responder_timeout *= APR_USEC_PER_SEC;
+if (sc-server-stapling_responder_timeout 0) {
+return SSLstapling_responder_timeout: invalid argument;
+}
+return NULL;
+}
Shouldn't we check these arguments for validity before using them,
rather than after?
Dan
RE: Using Authentication with flood
Anybody know anything about this? It's using libapr under the hood, but I couldn't find anything that indicates how that might translate into authentication for Flood. Eric -Original Message- From: Berg, Eric: IT (NYK) Sent: Friday, October 23, 2009 12:01 PM To: dev@httpd.apache.org Subject: Using Authentication with flood I'm trying to set up a regression test of sorts for my apache servers to verify new configs. I've been looking at Apache Flood, but I need to authenticate to my web servers and putting the username and password in to the URL doesn't seem to be working. How can I authenticate using flood? Thanks. Eric ___ This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unless specifically indicated, this e-mail is not an offer to buy or sell or a solicitation to buy or sell any securities, investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Barclays. Any views or opinions presented are solely those of the author and do not necessarily represent those of Barclays. This e-mail is subject to terms available at the following link: www.barcap.com/emaildisclaimer. By messaging with Barclays you consent to the foregoing. Barclays Capital is the investment banking division of Barclays Bank PLC, a company registered in England (number 1026167) with its registered office at 1 Churchill Place, London, E14 5HP. This email may relate to or be sent from other members of the Barclays Group. ___
Re: svn commit: r829619 - in /httpd/httpd/trunk: ./ modules/ssl/
On 10/26/2009 01:37 PM, Dan Poirier wrote:
jor...@apache.org writes:
Author: jorton
Date: Sun Oct 25 17:21:10 2009
New Revision: 829619
...
+const char *ssl_cmd_SSLStaplingResponseTimeSkew(cmd_parms *cmd, void *dcfg,
+const char *arg)
+{
+SSLSrvConfigRec *sc = mySrvConfig(cmd-server);
+sc-server-stapling_resptime_skew = atoi(arg);
+if (sc-server-stapling_resptime_skew 0) {
+return SSLstapling_resptime_skew: invalid argument;
+}
+return NULL;
+}
+
+const char *ssl_cmd_SSLStaplingResponseMaxAge(cmd_parms *cmd, void *dcfg,
+const char *arg)
+{
+SSLSrvConfigRec *sc = mySrvConfig(cmd-server);
+sc-server-stapling_resp_maxage = atoi(arg);
+if (sc-server-stapling_resp_maxage 0) {
+return SSLstapling_resp_maxage: invalid argument;
+}
+return NULL;
+}
+
+const char *ssl_cmd_SSLStaplingStandardCacheTimeout(cmd_parms *cmd, void
*dcfg,
+const char *arg)
+{
+SSLSrvConfigRec *sc = mySrvConfig(cmd-server);
+sc-server-stapling_cache_timeout = atoi(arg);
+if (sc-server-stapling_cache_timeout 0) {
+return SSLstapling_cache_timeout: invalid argument;
+}
+return NULL;
+}
+
+const char *ssl_cmd_SSLStaplingErrorCacheTimeout(cmd_parms *cmd, void *dcfg,
+ const char *arg)
+{
+SSLSrvConfigRec *sc = mySrvConfig(cmd-server);
+sc-server-stapling_errcache_timeout = atoi(arg);
+if (sc-server-stapling_errcache_timeout 0) {
+return SSLstapling_errcache_timeout: invalid argument;
+}
+return NULL;
+}
...
+const char *ssl_cmd_SSLStaplingResponderTimeout(cmd_parms *cmd, void *dcfg,
+const char *arg)
+{
+SSLSrvConfigRec *sc = mySrvConfig(cmd-server);
+sc-server-stapling_responder_timeout = atoi(arg);
+sc-server-stapling_responder_timeout *= APR_USEC_PER_SEC;
+if (sc-server-stapling_responder_timeout 0) {
+return SSLstapling_responder_timeout: invalid argument;
+}
+return NULL;
+}
Shouldn't we check these arguments for validity before using them,
rather than after?
Where do we use them so far?
The are the functions to process the directives.
Regards
Rüdiger
flood stuff
This is somewhat of a test for sending to the list and also a reply to Eric 1. Is the username/password getting to the server? You can check your logs or use tcpdump to be sure. 2. Are you trying to randomize this? 3. Are you using a round-robin profile? 4. Include your flood config file if it's not too long. Anybody know anything about this? It's using libapr under the hood, but I couldn't find anything that indicates how that might translate into authentication for Flood. Eric -Original Message- From: Berg, Eric: IT (NYK) Sent: Friday, October 23, 2009 12:01 PM To: dev@httpd.apache.org Subject: Using Authentication with flood I'm trying to set up a regression test of sorts for my apache servers to verify new configs. I've been looking at Apache Flood, but I need to authenticate to my web servers and putting the username and password in to the URL doesn't seem to be working. How can I authenticate using flood? Thanks. Eric
Re: svn commit: r829619 - in /httpd/httpd/trunk: ./ modules/ssl/
Ruediger Pluem rpl...@apache.org writes:
On 10/26/2009 01:37 PM, Dan Poirier wrote:
jor...@apache.org writes:
Author: jorton
Date: Sun Oct 25 17:21:10 2009
New Revision: 829619
...
+const char *ssl_cmd_SSLStaplingResponseTimeSkew(cmd_parms *cmd, void *dcfg,
+const char *arg)
+{
+SSLSrvConfigRec *sc = mySrvConfig(cmd-server);
+sc-server-stapling_resptime_skew = atoi(arg);
+if (sc-server-stapling_resptime_skew 0) {
+return SSLstapling_resptime_skew: invalid argument;
+}
+return NULL;
+}
Shouldn't we check these arguments for validity before using them,
rather than after?
Where do we use them so far?
The are the functions to process the directives.
I meant that we assign a new value to the configuration before we know
whether that new value is valid.
It now occurs to me that while the code in isolation looks suspicious,
returning an error means the server won't start, so the point is moot.
Never mind.
Dan
Re: svn commit: r829619 - in /httpd/httpd/trunk: ./ modules/ssl/
Hi Joe, Steve,
I have some probs with getting this compiled;
first its inclear for me from where HAVE_OCSP should get defined in
ssl_toolkit.compat.h - for me it seems its not defined in line 42, thus
#include openssl/ocsp.h
in line 44 is not included, and causes compile errors on NetWare since
later on in line 150 we have:
#if (OPENSSL_VERSION_NUMBER = 0x00908080)
#ifndef OPENSSL_NO_TLSEXT
#define HAVE_OCSP_STAPLING
#endif
#endif
so HAVE_OCSP_STAPLING gets defined when !OPENSSL_NO_TLSEXT although
ocsp.h was not included.
After I defined HAVE_OCSP manually with CFLAGS I come to next error in
line 110 of ssl_utl_stapling.c where STACK is not defined; I've searched
both OpenSSL 0.9.8 and 1.0.0 branches, but couldnt find anything but
only _STACK in crypto/stack/stack.h with the hint:
/* Use STACK_OF(...) instead */
so shouldnt line 110 be:
Index: ssl_util_stapling.c
===
--- ssl_util_stapling.c (revision 830045)
+++ ssl_util_stapling.c (working copy)
@@ -107,7 +107,7 @@
{
certinfo *cinf;
X509 *issuer = NULL;
-STACK *aia = NULL;
+STACK_OF(OPENSSL_STRING) *aia = NULL;
if (x == NULL)
return 0;
Gün.
Re: svn commit: r829619 - in /httpd/httpd/trunk: ./ modules/ssl/
Guenter Knauf wrote:
After I defined HAVE_OCSP manually with CFLAGS I come to next error in
line 110 of ssl_utl_stapling.c where STACK is not defined; I've searched
both OpenSSL 0.9.8 and 1.0.0 branches, but couldnt find anything but
only _STACK in crypto/stack/stack.h with the hint:
/* Use STACK_OF(...) instead */
so shouldnt line 110 be:
Index: ssl_util_stapling.c
===
--- ssl_util_stapling.c (revision 830045)
+++ ssl_util_stapling.c (working copy)
@@ -107,7 +107,7 @@
{
certinfo *cinf;
X509 *issuer = NULL;
-STACK *aia = NULL;
+STACK_OF(OPENSSL_STRING) *aia = NULL;
if (x == NULL)
return 0;
Erk, shows how long it was since I wrote that. OPENSSL_STRING is only defined in
1.0.0. It should work with STACK in 0.9.8 though: that is defined in
crypto/stack/stack.h I'll work on a fix for both branches.
Steve.
--
Dr Stephen N. Henson. Senior Technical/Cryptography Advisor,
Open Source Software Institute: www.oss-institute.org
OpenSSL Core team: www.openssl.org
