Re: [PATCH] Backport patch for CVE-2009-3555 from Apache 2.x
I updated the patch. The most recent version is now available at
http://people.apache.org/~rjung/patches/cve-2009-3555_mod_ssl_2_8_31-1_3_41-v4.patch
In addition to the v3 version of the patch, it now also contains a
backport of the SSLInsecureRenegotiation directive introduced in Apache
httpd 2.2.15 in combination with OpenSSL 0.9.8m and beyond.
The patch needs some more testing, but backport was straightforward.
Regards,
Rainer
On 01.01.2010 21:44, Rainer Jung wrote:
On 29.12.2009 22:57, John Lightsey wrote:
On Mon, 2009-11-23 at 22:12 +0100, Rainer Jung wrote:
On 23.11.2009 18:57, John Lightsey wrote:
On Sun, 2009-11-22 at 01:21 +0100, Rainer Jung wrote:
Thanks again. I updated the patch:
http://people.apache.org/~rjung/patches/cve-2009-3555_mod_ssl_2_8_21-1_3_41-v2.patch
The only changes are in ssl_engine_io.c, where the declaration of char
*reneg is moved 4 times to the beginning of the function. Anything else
you observed?
I received a report of segfaults caused by this patch. They happen when
you have Apache proxy connections to a SSL destination. IE:
RewriteRule ^/(.*) https://other_site.com/$1 [P]
The segfault happens at:
reneg = ap_ctx_get(c-client-ctx, ssl::reneg);
in ssl_io_suck_read() because SSL_get_app_data(ssl) returns NULL.
#0 0x00454bb5 in ssl_io_suck_read (ssl=0x10a26070,
buf=0x107ccd88 UserDir, len=4096) at ssl_engine_io.c:275
actx = (ap_ctx *) 0x10a26070
ss = (struct ssl_io_suck_st *) 0x0
r = (request_rec *) 0x0
rv = 0
reneg = 0x0
c = (conn_rec *) 0x0
#1 0x00454f31 in ssl_io_hook_read (fb=0x10a25c28,
buf=0x107ccd88 UserDir, len=4096) at ssl_engine_io.c:394
ssl = (SSL *) 0x10a26070
c = (conn_rec *) 0x0
s = (server_rec *) 0x0
rc = 0
reneg = 0x0
#2 0x0049a00f in ap_hook_call_func (ap=0x7fff98699110,
he=0x104f33b0, hf=0x105059c0) at ap_hook.c:649
v1 = (void *) 0x10a25c28
v2 = (void *) 0x107ccd88
v3 = 4096
v_rc = (void *) 0x7fff9869922c
v_tmp = {v_char = 0 '\0', v_int = 0, v_long = 0, v_float = 0,
v_double = 0, v_ptr = 0x0}
rc = 1
#3 0x004982db in ap_hook_call (hook=0x4bbb5a ap::buff::read)
at ap_hook.c:382
i = 0
he = (ap_hook_entry *) 0x104f33b0
ap = {{gp_offset = 40, fp_offset = 48, overflow_arg_area =
0x7fff98699200, reg_save_area = 0x7fff98699140}}
rc = 0
#4 0x0046af22 in ap_read (fb=0x10a25c28, buf=0x107ccd88,
nbyte=4096) at buff.c:255
rv = 0
Thank you for your feedback and the analysis. I could reproduce this and
have updated the patch:
http://people.apache.org/~rjung/patches/cve-2009-3555_mod_ssl_2_8_21-1_3_41-v3.patch
I tested with and without SSL_EXPERIMENTAL_PROXY and it worked for my
tests. The code doesn't try to change/fix renegotiation behaviour for
ssl on the client side when used as a proxy.
As always: feedback welcome!
Regards,
Rainer
__
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List modssl-users@modssl.org
Automated List Manager majord...@modssl.org
__
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List modssl-users@modssl.org
Automated List Managermajord...@modssl.org
Re: [PATCH] Backport patch for CVE-2009-3555 from Apache 2.x
On 29.12.2009 22:57, John Lightsey wrote:
On Mon, 2009-11-23 at 22:12 +0100, Rainer Jung wrote:
On 23.11.2009 18:57, John Lightsey wrote:
On Sun, 2009-11-22 at 01:21 +0100, Rainer Jung wrote:
Thanks again. I updated the patch:
http://people.apache.org/~rjung/patches/cve-2009-3555_mod_ssl_2_8_21-1_3_41-v2.patch
The only changes are in ssl_engine_io.c, where the declaration of char
*reneg is moved 4 times to the beginning of the function. Anything else
you observed?
I received a report of segfaults caused by this patch. They happen when
you have Apache proxy connections to a SSL destination. IE:
RewriteRule ^/(.*) https://other_site.com/$1 [P]
The segfault happens at:
reneg = ap_ctx_get(c-client-ctx, ssl::reneg);
in ssl_io_suck_read() because SSL_get_app_data(ssl) returns NULL.
#0 0x00454bb5 in ssl_io_suck_read (ssl=0x10a26070,
buf=0x107ccd88 UserDir, len=4096) at ssl_engine_io.c:275
actx = (ap_ctx *) 0x10a26070
ss = (struct ssl_io_suck_st *) 0x0
r = (request_rec *) 0x0
rv = 0
reneg = 0x0
c = (conn_rec *) 0x0
#1 0x00454f31 in ssl_io_hook_read (fb=0x10a25c28,
buf=0x107ccd88 UserDir, len=4096) at ssl_engine_io.c:394
ssl = (SSL *) 0x10a26070
c = (conn_rec *) 0x0
s = (server_rec *) 0x0
rc = 0
reneg = 0x0
#2 0x0049a00f in ap_hook_call_func (ap=0x7fff98699110,
he=0x104f33b0, hf=0x105059c0) at ap_hook.c:649
v1 = (void *) 0x10a25c28
v2 = (void *) 0x107ccd88
v3 = 4096
v_rc = (void *) 0x7fff9869922c
v_tmp = {v_char = 0 '\0', v_int = 0, v_long = 0, v_float = 0,
v_double = 0, v_ptr = 0x0}
rc = 1
#3 0x004982db in ap_hook_call (hook=0x4bbb5a ap::buff::read)
at ap_hook.c:382
i = 0
he = (ap_hook_entry *) 0x104f33b0
ap = {{gp_offset = 40, fp_offset = 48, overflow_arg_area =
0x7fff98699200, reg_save_area = 0x7fff98699140}}
rc = 0
#4 0x0046af22 in ap_read (fb=0x10a25c28, buf=0x107ccd88,
nbyte=4096) at buff.c:255
rv = 0
Thank you for your feedback and the analysis. I could reproduce this and
have updated the patch:
http://people.apache.org/~rjung/patches/cve-2009-3555_mod_ssl_2_8_21-1_3_41-v3.patch
I tested with and without SSL_EXPERIMENTAL_PROXY and it worked for my
tests. The code doesn't try to change/fix renegotiation behaviour for
ssl on the client side when used as a proxy.
As always: feedback welcome!
Regards,
Rainer
__
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List modssl-users@modssl.org
Automated List Managermajord...@modssl.org
Re: [PATCH] Backport patch for CVE-2009-3555 from Apache 2.x
On 23.11.2009 18:57, John Lightsey wrote: On Sun, 2009-11-22 at 01:21 +0100, Rainer Jung wrote: Backport is not totally straightforward, because the original patches use the filter architecture not present in Apache 1.3. Any Feedback on the patch is welcome. Some additional debug output can be activated by using -DRENEG_DEBUG. There are a few lines of c99 syntax in this patch (variable declarations of char *reneg in the middle of code) that cause it to fail with gcc 2.95. Sorry, I forgot to fix those. Thanks for the feedback. Seems to work fine otherwise. Good to know! The more eyes the better. Regards, Rainer __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List modssl-users@modssl.org Automated List Managermajord...@modssl.org
[PATCH] Backport patch for CVE-2009-3555 from Apache 2.x
Hi, I backported the patch against CVE-2009-3555 from Apache trunk, 2.2 and 2.0 (proposed). The patch is available at http://people.apache.org/~rjung/patches/cve-2009-3555_mod_ssl_2_8_21-1_3_41.patch CVE-2009-3555 is about the Man in the Middle attack against HTTPS. The patch disables the use of client initiated SSL renegotiation. Server initiated reneg is still allowed (and vulnerable). See also: http://svn.apache.org/viewvc?rev=833582view=rev http://svn.apache.org/viewvc?rev=833622view=rev http://people.apache.org/~rjung/patches/cve-2009-3555_httpd_2_0_x-v2.patch Backport is not totally straightforward, because the original patches use the filter architecture not present in Apache 1.3. Any Feedback on the patch is welcome. Some additional debug output can be activated by using -DRENEG_DEBUG. Regards, Rainer __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List modssl-users@modssl.org Automated List Managermajord...@modssl.org
Difficult real world ssl problem
Hi, we encounter a strange ssl client behaviour on a high load web site. The setup is as follows: The webserver is Apache 1.3.26 with mod_ssl 2.8.10 and openssl 0.9.6e. It has a VeriSign certificate with strong encryption enabled (GlobalID, corrsponding to SGC in MSIE and Internal SteUp in Netscape) and the hardware ist based on a Sun Solaris E420R, 4 CPUs and NCipher Crypto accelerator. mod_ssl uses shmht-session cache. No Keep-Alive is used. The whole site worked very good for more than a year. Then unfortunately too many configurations were changed at the same time (Webserver config, load-balancers, virtual hosts, firewalls). Now we can see a lot of requests which are no longer able to negotiate strong encryption. In fact, initially the browsers successfully connect and some requests work, but suddenly we can see requests from the same clients using weak encryption, which then is rejected by the web server config. All cases are MSIE Browsers, but a lot of different versions and Windows variants. It looks like browser upgrade to strong encryption helps, but also weak browsers could use the site without problems because the certificate has step-up ability coded in. I describe one case as an example: 1) The first request of the client to the webserver gets the homepage. The Request ist successful and uses 128Bit RC4-MD5. The answer is a frameset. 2) The Browser connects again to get the first of the two frames in the frameset. It successfully resumes the SSL-Session. 3) The Browser connects again to get the second frame in the frameset. Now the request is rejected and the logfile says the Client tried to use EXP-RC4-MD5 40 Bit. Using tcpdump/ssldump we can see the good requests 1) and 2) but for 3) ssldump only outputs: New TCP connection #3: CLIENT-IP(63867) - SERVER-IP(443) Version 2 Client. 31038388800.4248 (0.1196) SC TCP FIN 31038388800.4273 (0.0024) CS TCP FIN although there are a lot of packets in the tcpdump capture file, and verbose tcpdump with hexdump shows, that for instance in the packets are strings from the certificate. 4) The Client goes on successfully using the ssl connection from 1) and 2). Now the question is: Do you have any idea, why one request in the middle of the sessions uses SSL Version 2? Yours sincerely, Rainer Jung kippdata informationstechnologie GmbH Bornheimer Straße 33a D-53111 Bonn Germany Tel.: +49/228/98549-0 Fax: +49/228/98549-50 email: [EMAIL PROTECTED] __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
bugdb
Hi, does anybody know, why the mod_ssl bugdb is not accessible at the moment? The link to the bugdb on the support page only gives the listing of a directory, instead of activating the cgi. Maybe someone is able to repair it. Thanks for your help Rainer Jung kippdata informationstechnologie GmbH Bornheimer Straße 33a D-53111 Bonn Germany Tel.: +49/228/98549-0 Fax: +49/228/98549-50 email: [EMAIL PROTECTED] __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: A bug in table_adjust function that causes a core dump
Hi, I would be very interested if there is any progress concerning this bug (table_adjust in ssl_util_table.c). Are there plans to include the fix in the code? Has the bug been reproduced? Also there was another Bug found some weeks ago concerning a memory leak when using client certificates. The bugfix obviously is now in the CVS tree. Does anyone know, when this code will be released (most liekely as 2.8.13)? Any answers would be very helpful, because we care about a site which is very soon starting to heavily use client certificates and also we observed a lot of apache processes core dumping on friday (not related to the certificates). Best regards, Rainer Jung kippdata informationstechnologie GmbH Bornheimer Straße 33a D-53111 Bonn Germany Tel.: +49/228/98549-0 Fax: +49/228/98549-50 email: [EMAIL PROTECTED] At 16:26 08.11.02, you wrote: Hi folks, I have found a bug in table_adjust function, and I haven't seen any reports about this error in the mailing list. Also, this error is not fixed in the current version of mod_ssl (2.8.12). THE BUG - ssl_util_table.c file, line 1755: buckets = (table_entry_t **) table_p-ta_calloc(buck_n, sizeof(table_entry_t *)); if (table_p-ta_buckets == NULL) return TABLE_ERROR_ALLOC; buckets variable is not checked here and this causes a coredump when the table size is big and there is no memory for reallocating the buckets. Below is a stack dump from Solaris 8 running Apache 1.3.26 + mod_ssl 2.8.10 + OpenSSL 0.9.6g: ... --- called from signal handler with signal 11 (SIGSEGV) --- 00089b60 table_adjust (0, fe0a09cc, fe09ea84, 0, 3e9, fe08cdd8) + d0 00081cac ssl_scache_shmht_expire (1, 20, fe0e436c, 4, 31, fe08e438) + 130 00081a24 ssl_scache_shmht_store (94, 18aef0, 20, bb8200, bb81b8, 1ad4e0) + 11c 0007b7e0 ssl_callback_NewSessionCacheEntry (bb8200, 3dc42bfb, 7b784, 1ad4e0, bb81b8, ba65e0) + 5c fe64c584 ssl_update_cache (a1c458, 2, 21c1, 1ad4e0, 1, a1c458) + a8 fe63ef14 ssl3_accept (a1c458, 2100, 21c0, 3004, 90, 0) + 8c8 fe64d520 SSL_accept (a1c458, fe63e64c, 1, ba1088, 10, ba109a) + 24 fe648d94 ssl23_get_client_hello (2a, 70, 2, ffbef100, 1, a1c458) + 7cc fe648528 ssl23_accept (a1c458, fe648388, 1a1f70, 0, 6f757400, 6f757400) + 1a0 fe64d520 SSL_accept (a1c458, 79d30, 12c, 0, 16fab0, 17cee0) + 24 00079730 ssl_hook_NewConnection (908cc0, 178000, 1781d0, ffbef2cc, 16fa34, 806478) + 2b4 0004c4a0 new_connection (163b1c, 45415049, 908cc0, ffbef344, ffbef344, 3) + 114 0004d470 child_main (173400, 173400, 173400, ff36b228, ff365958, ff35efb8) + 634 ... HOW TO REPRODUCE -- I was able to reproduce the error in the following way: 1. Set SSLSessionCacheTimeout to 20 minutes 2. Set SSLSessionCache size to 1024000 (or a value that is close to your EAPI_MM_CORE_MAXSIZE). 3. Set ExtendedStatus to On 4. Start the server and run a script like the following one: #!/usr/local/bin/bash i=0 while expr $i \ 400 /dev/null; do echo $i i=`expr $i + 1` for j in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15; do curl -I https://your.host/ done sleep 1 done BTW, you may interrupt the script when the current sessions parameter at the bottom of the server status page (https://your.host/server-status) have stopped growing. 5. Wait 25 minutes from the time you have started the script and reload the server status page or access the server over SSL. Most likely you will see a core dump. THE FIX If we change the if statement like this:.. if (table_p-ta_buckets == NULL || buckets == NULL) return TABLE_ERROR_ALLOC; ...the server doesn't dump core in the test. Another solution to this problem is to decrease shared memory size in the config file. Best regards, Kirill Shirokov, St. Petersburg, Russia. __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED] __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
openssl0.9.6e ok with mod_ssl 2.8.10?
Hi, will there be a new version of mod_ssl for the security fixed openssl 0.9.6e and openssl-engine 0.9.6e or is it safe to use mod_ssl 2.8.10. If there will be a new version: is there an expected release date/time? Thanks for any answers! Rainer Jung kippdata informationstechnologie GmbH Bornheimer Straße 33a D-53111 Bonn Germany Tel.: +49/228/98549-0 Fax: +49/228/98549-50 email: [EMAIL PROTECTED] __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Problem session cache and HTTP headers AOL
) applicationent-Type: application/x-www-form-urlencoded
1 Mozilla/4.0 (compatible; MSIE 5.0; AOL 5.0; Windows 98; DigExt;
QXW03314) applicationent-Type: application/x-www-form-urlencoded
1 Mozilla/4.0 (compatible; MSIE 5.0; AOL 5.0; Windows 98; DigExt;
MIST1.01) applicationent-Type: application/x-www-form-urlencoded
1 Mozilla/4.0 (compatible; MSIE 5.0; AOL 5.0; Windows 98; DigExt;
AIS3.01) applicationent-Type: application/x-www-form-urlencoded
1 Mozilla/4.0 (compatible; MSIE 5.0; AOL 5.0; Windows 98; DigExt; 11
Internet AG) applicationent-Type: application/x-www-form-urlencoded
1 Mozilla/4.0 (compatible; MSIE 5.0; AOL 5.0; Windows 98; DigExt)
application;q=0.7,fr;q=0.3, application/x-www-form-urlencoded
1 Mozilla/4.0 (compatible; MSIE 5.0; AOL 5.0; Windows 98; DigExt)
application;q=0.5, application/x-www-form-urlencoded
1 Mozilla/4.0 (compatible; MSIE 5.0; AOL 5.0; Windows 98; DT; Quicken
98 DE; DigExt) applicationent-Type: application/x-www-form-urlencoded
1 Mozilla/4.0 (compatible; MSIE 5.0; AOL 5.0; Windows 98; DT; DigExt)
applicationent-Type: application/x-www-form-urlencoded
1 Mozilla/4.0 (compatible; MSIE 5.0; AOL 5.0; Windows 98)
applicationent-Type: application/x-www-form-urlencoded
1 Mozilla/4.0 (compatible; MSIE 5.0; AOL 5.0; Windows 95; DigExt;
debitel.net 3.0) applicationent-Type: application/x-www-form-urlencoded
1 Mozilla/4.0 (compatible; MSIE 5.0; AOL 5.0; Windows 95; DigExt)
applicationontent-Type: application/x-www-form-urlencoded
1 Mozilla/4.0 (compatible; MSIE 5.0; AOL 5.0; Windows 95; DigExt)
application0.5, application/x-www-form-urlencoded
1 Mozilla/4.0 (compatible; MSIE 5.0; AOL 4.0; Windows 98; DigExt;
T-Online Internatinal AG) applicationent-Type:
application/x-www-form-urlencoded
1 Mozilla/4.0 (compatible; MSIE 5.0; AOL 4.0; Windows 98; DigExt;
QXW03018) applicationent-Type: application/x-www-form-urlencoded
1 Mozilla/4.0 (compatible; MSIE 5.0; AOL 4.0; Windows 98; DigExt; DT)
applicationent-Type: application/x-www-form-urlencoded
1 Mozilla/4.0 (compatible; MSIE 5.0; AOL 4.0; Windows 95; DigExt)
applicationent-Type: application/x-www-form-urlencoded
1 Mozilla/4.0 (compatible; MSIE 5.0; AOL 4.0; Windows 95; DT;
talknet2.0; DigExt) applicationent-Type: application/x-www-form-urlencoded
At 20:08 25.09.01 , you wrote:
I think that this is important, as I am having specific issues with AOL
customers getting errors. Can you tell
me how to independently verify this problem? How do you find the
Content-type header that the browser
(AOL) receives when running SSL?
Problem Browsers
-
Mozilla/4.0 (compatible; MSIE 5.0; Mac_PowerPC)
Mozilla/4.0 (compatible; MSIE 5.0; AOL 6.0; Windows 98; Compaq; DigEx)
Mozilla/4.0 (compatible; MSIE 5.0; AOL 5.0; Windows 95; DigExt)
Ok Browsers
-
Mozilla/4.0 (compatible; MSIE 4.01; AOL 6.0; Windows 98)
Mozilla/4.0 (compatible; MSIE 5.0; CS 2000; Windows 98; DigExt)
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 4.0)
Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)
Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
Mozilla/4.0 (compatible; MSIE 5.0; Windows 95; DigExt; TUCOWS)
Mozilla/4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC)
Mozilla/4.78 (Macintosh; U; PPC)
Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt)
Mozilla/4.0 (compatible; MSIE 5.01; Windows NT)
Nick
*** REPLY SEPARATOR ***
On 9/25/2001 at 12:21 PM Rainer Jung wrote:
But even if the address changes:
as far as SSL is concerned they connect successful, but the
Content-Type-header corruption looks like a bug in memory allocation. So
some special AOL behaviour might be responsible for running through parts
of mod_ssl code which are rarely used and might contain the bug.
By the way: is there a way to sniff the ssl communication and decode later
on with session cache enabled? The only tool I know is ssldump and that
one
does not work with the cache enabled, because it doesn't remember the keys
for using when the session is resumed. That's the reason we some time had
to disable the cache (we wanted to debug another problem) and then noticed
that the AOL problem also went away.
At 11:59 25.09.01 , you wrote:
On Tue, Sep 25, 2001 at 11:46:24AM +0200, Rainer Jung wrote:
Hi,
we notice the following problem:
HTTP-Header Content-Type gets corrupt in rare cases for AOL users, if
we
enable shared memory ssl session cache.
Setup: We have apache 1.3.14 with mod_ssl (I don't have the version at
hand). Behind we use tomcat 3.2.23 on the same system to respond to
JSP-requests. Betwenn apache and tomcat we use mod_jk with ajp13. We
noticed, that tomcat sometimes did not find the contents of the POST
buffer
and found out, that already before parsing the Request to tomcat, the
Content-Type-Header of the request, which we can print out early in
mod_jk
is corrupt. It contains a concatenation of the correct string
x
Re: Problem session cache and HTTP headers AOL
Hi,
we verified the problem in two ways: First we used mod_log_config to log
incoming Content-Type-Header (include %{Content-Type}i in your log
format) . Since this occurs late in the processing we additionally did
another thing: I patched mod_jk, the module passing over the request to
tomcat, to log the complete POST-Buffer at the moment the request is
processed. Both logfiles contained the same corruption.
I will produce a list of seen header values and of browser types but this
might take one or two days. Also since Eric Rescorla provided ssldump with
cache-awareness, we can now snoop the traffic to show the headers even
before they go to apache, so we can see, if they are already corrupt, at
the time they arrive.
I will give more information when available. What are your AOL related
problems?
Thanks so far
Rainer Jung
At 20:08 25.09.01 , you wrote:
I think that this is important, as I am having specific issues with AOL
customers getting errors. Can you tell
me how to independently verify this problem? How do you find the
Content-type header that the browser
(AOL) receives when running SSL?
Problem Browsers
-
Mozilla/4.0 (compatible; MSIE 5.0; Mac_PowerPC)
Mozilla/4.0 (compatible; MSIE 5.0; AOL 6.0; Windows 98; Compaq; DigEx)
Mozilla/4.0 (compatible; MSIE 5.0; AOL 5.0; Windows 95; DigExt)
Ok Browsers
-
Mozilla/4.0 (compatible; MSIE 4.01; AOL 6.0; Windows 98)
Mozilla/4.0 (compatible; MSIE 5.0; CS 2000; Windows 98; DigExt)
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 4.0)
Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)
Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
Mozilla/4.0 (compatible; MSIE 5.0; Windows 95; DigExt; TUCOWS)
Mozilla/4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC)
Mozilla/4.78 (Macintosh; U; PPC)
Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt)
Mozilla/4.0 (compatible; MSIE 5.01; Windows NT)
Nick
*** REPLY SEPARATOR ***
On 9/25/2001 at 12:21 PM Rainer Jung wrote:
But even if the address changes:
as far as SSL is concerned they connect successful, but the
Content-Type-header corruption looks like a bug in memory allocation. So
some special AOL behaviour might be responsible for running through parts
of mod_ssl code which are rarely used and might contain the bug.
By the way: is there a way to sniff the ssl communication and decode later
on with session cache enabled? The only tool I know is ssldump and that
one
does not work with the cache enabled, because it doesn't remember the keys
for using when the session is resumed. That's the reason we some time had
to disable the cache (we wanted to debug another problem) and then noticed
that the AOL problem also went away.
At 11:59 25.09.01 , you wrote:
On Tue, Sep 25, 2001 at 11:46:24AM +0200, Rainer Jung wrote:
Hi,
we notice the following problem:
HTTP-Header Content-Type gets corrupt in rare cases for AOL users, if
we
enable shared memory ssl session cache.
Setup: We have apache 1.3.14 with mod_ssl (I don't have the version at
hand). Behind we use tomcat 3.2.23 on the same system to respond to
JSP-requests. Betwenn apache and tomcat we use mod_jk with ajp13. We
noticed, that tomcat sometimes did not find the contents of the POST
buffer
and found out, that already before parsing the Request to tomcat, the
Content-Type-Header of the request, which we can print out early in
mod_jk
is corrupt. It contains a concatenation of the correct string
x-www-form-urlencoded with a part of the string Content-Type and then
again x-www-form-urlencoded.
The problem only happened to users coming from AOL, but for diverse
browsers. But: is we disable the session cache (shm) the problems
vanishes.
Platform is Solaris 2.6. The site is high-volume and uses strong
encryption. The problem is not strictly User or Browser dependant, it
occurs kind of statistically but only for Clients coming from
AOL-IP-adresses and only if session cache is enabled. Apart from that
communication seems to work good.
Any comments?
Strange - usually people run into problems when they don't have their
session
cache on :)
Since this probably is AOL specific, perhaps it happens because they
proxy
their
ssl connections. AFAIK they proxy outgoing connections (at least for
HTTP) and
you can't be sure that all requests from a user will be comming from the
same
proxy even over a short period of time. I don't know if this is the case,
but
raising your SSLLogLevel such that you can see wether it is session cache
hits
or misses and wether the ip adress changes.
vh
Mads Toftum
--
With a rubber duck, one's never alone.
-- The Hitchhiker's Guide to the Galaxy
__
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List [EMAIL PROTECTED
Problem session cache and HTTP headers AOL
Hi, we notice the following problem: HTTP-Header Content-Type gets corrupt in rare cases for AOL users, if we enable shared memory ssl session cache. Setup: We have apache 1.3.14 with mod_ssl (I don't have the version at hand). Behind we use tomcat 3.2.23 on the same system to respond to JSP-requests. Betwenn apache and tomcat we use mod_jk with ajp13. We noticed, that tomcat sometimes did not find the contents of the POST buffer and found out, that already before parsing the Request to tomcat, the Content-Type-Header of the request, which we can print out early in mod_jk is corrupt. It contains a concatenation of the correct string x-www-form-urlencoded with a part of the string Content-Type and then again x-www-form-urlencoded. The problem only happened to users coming from AOL, but for diverse browsers. But: is we disable the session cache (shm) the problems vanishes. Platform is Solaris 2.6. The site is high-volume and uses strong encryption. The problem is not strictly User or Browser dependant, it occurs kind of statistically but only for Clients coming from AOL-IP-adresses and only if session cache is enabled. Apart from that communication seems to work good. Any comments? Rainer Jung kippdata informationstechnologie GmbH Bornheimer Straße 33a D-53111 Bonn Tel.: +49/228/98549-0 Fax: +49/228/98549-50 email: [EMAIL PROTECTED] At 11:25 25.09.01 , you wrote: I believe he is refering to these files being ceated under the apache logs/ dir: httpd.mm.11934.sem httpd.mm.11961.sem ... And, I believe they are menat to be there as he is using mm for apache memory management. But my apache instalation in not under /usr/local/apache ,while mm module tryes to create file only under /usr/local/apache/logs directory no matter where apache is really installed. And if I create a dummy directory /usr/local/apache/logs then it works fine. So my question is, how can i make the mm module create files under real apache instalation dir. Thanks. __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED] kippdata informationstechnologie GmbH Bornheimer Straße 33a 53111 Bonn Tel.: 0228/98549-0 Fax: 0228/98549-50 email: [EMAIL PROTECTED] __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
Re: Problem session cache and HTTP headers AOL
But even if the address changes: as far as SSL is concerned they connect successful, but the Content-Type-header corruption looks like a bug in memory allocation. So some special AOL behaviour might be responsible for running through parts of mod_ssl code which are rarely used and might contain the bug. By the way: is there a way to sniff the ssl communication and decode later on with session cache enabled? The only tool I know is ssldump and that one does not work with the cache enabled, because it doesn't remember the keys for using when the session is resumed. That's the reason we some time had to disable the cache (we wanted to debug another problem) and then noticed that the AOL problem also went away. At 11:59 25.09.01 , you wrote: On Tue, Sep 25, 2001 at 11:46:24AM +0200, Rainer Jung wrote: Hi, we notice the following problem: HTTP-Header Content-Type gets corrupt in rare cases for AOL users, if we enable shared memory ssl session cache. Setup: We have apache 1.3.14 with mod_ssl (I don't have the version at hand). Behind we use tomcat 3.2.23 on the same system to respond to JSP-requests. Betwenn apache and tomcat we use mod_jk with ajp13. We noticed, that tomcat sometimes did not find the contents of the POST buffer and found out, that already before parsing the Request to tomcat, the Content-Type-Header of the request, which we can print out early in mod_jk is corrupt. It contains a concatenation of the correct string x-www-form-urlencoded with a part of the string Content-Type and then again x-www-form-urlencoded. The problem only happened to users coming from AOL, but for diverse browsers. But: is we disable the session cache (shm) the problems vanishes. Platform is Solaris 2.6. The site is high-volume and uses strong encryption. The problem is not strictly User or Browser dependant, it occurs kind of statistically but only for Clients coming from AOL-IP-adresses and only if session cache is enabled. Apart from that communication seems to work good. Any comments? Strange - usually people run into problems when they don't have their session cache on :) Since this probably is AOL specific, perhaps it happens because they proxy their ssl connections. AFAIK they proxy outgoing connections (at least for HTTP) and you can't be sure that all requests from a user will be comming from the same proxy even over a short period of time. I don't know if this is the case, but raising your SSLLogLevel such that you can see wether it is session cache hits or misses and wether the ip adress changes. vh Mads Toftum -- With a rubber duck, one's never alone. -- The Hitchhiker's Guide to the Galaxy __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED] __ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager[EMAIL PROTECTED]
