Bug 123585 - (IT_53263) mod_ssl per-directory renegotiation with request body
mod_ssl per-directory renegotiation with request body
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: httpd (Show other bugs)
3.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Joe Orton
:
Depends On:
Blocks: 170445
  Show dependency treegraph
 
Reported: 2004-05-19 10:44 EDT by Nicolai Schleifer
Modified: 2007-11-30 17:07 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-01-09 11:38:39 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
sysreport output of the problematic system (161.33 KB, application/x-bzip2)
2004-05-19 10:52 EDT, Nicolai Schleifer
no flags Details
sysreport output of the problematic system (161.33 KB, application/x-bzip2)
2004-05-19 11:04 EDT, Nicolai Schleifer
no flags Details

  None (edit)
Description Nicolai Schleifer 2004-05-19 10:44:18 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040323

Description of problem:
The following VirtualHost configuration does exist in our system:

<VirtualHost 62.154.147.165:443>
        #
        # Globale Sicherheitseinstellungen
        #

        # TRACE/TRACK method
        RewriteEngine On
        RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
        RewriteRule .* - [F]

        # Access to CVS files
        <Files ~ "Entries|Entries.Log|Repository|Root">
                Order allow,deny
                Deny from all
        </Files>

        ServerAdmin support@chamaeleon.de
        DocumentRoot /export/data/kunden/www4.chamaeleon.de
        ServerName secure.chamaeleon.de
        CustomLog /var/log/httpd/secure.chamaeleon.de/access.log
common_upload
        ErrorLog /var/log/httpd/secure.chamaeleon.de/error.log
        ErrorDocument 403 /403-7.htm
        SSLEngine On
        SSLCipherSuite
ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
        SSLCertificateFile
/etc/httpd/conf/secure.chamaeleon.de/secure.chamaeleon.de.crt
        SSLCertificateKeyFile
/etc/httpd/conf/secure.chamaeleon.de/secure.chamaeleon.de.ohnepwd.key
        SSLCACertificateFile
/etc/httpd/conf/secure.chamaeleon.de/secure.chamaeleon.de.crt
        <Directory
/export/data/kunden/www4.chamaeleon.de/adg/portalmanager>
               SSLOptions +OptRenegotiate
               SSLVerifyClient require
               SSLVerifyDepth  1
        </Directory>
        php_flag register_globals on
        php_flag file_uploads on
        AddType application/x-httpd-php .php4 .php3 .phtml .php
        AddType application/x-httpd-php-source .phps
</VirtualHost>

The directory
"/export/data/kunden/www4.chamaeleon.de/adg/portalmanager" contains
the script that works on the form-submitted contents. It is protected
by a client certificate and the configuration seems straightforward.

After a while of using it we get "Method POST not allowed" when trying
to use the script.

We found documentation about this problem which is know since
Apache-1.3.x. The SSL option "OptRenegotiate", as you can see in the
directory clause, does not help. We placed it also before and after
the directory clause and also removed it altogether.

In any case we were able to reproduce the problem.

Ralf Engelschall, the developer of mod_ssl, recommends to upgrade to
mod_ssl-2.5.0, which is quite old. It seems that this bug returned
somehow to the surface..

After some requests the renegotiation happens and results in the
request being forbidden. Please also see the sysreport and the
following log snippet from the Apache errorlog:

[Wed May 19 15:28:01 2004] [error] Re-negotiation handshake failed:
Not accepted by client!?
[Wed May 19 15:28:40 2004] [error] SSL Re-negotiation in conjunction
with POST method not supported!!hint: try SSLOptions +OptRenegotiate



Version-Release number of selected component (if applicable):
mod_ssl-2.0.46-32.ent

How reproducible:
Always

Steps to Reproduce:
1. Repeatedly submit form with some arbitrary data until errormessage
appears
2.
3.
    

Actual Results:  Method POST not allowed
Errormessage from Apache.


Expected Results:  Normal form data handling.

Additional info:

There's really nothing obviously special about this.
Comment 1 Nicolai Schleifer 2004-05-19 10:52:37 EDT
Created attachment 100340 [details]
sysreport output of the problematic system

Maybe helpful.
Comment 2 Nicolai Schleifer 2004-05-19 11:04:30 EDT
Created attachment 100344 [details]
sysreport output of the problematic system

Maybe helpful.
Comment 3 Joe Orton 2004-05-19 11:10:18 EDT
Thanks for the report.

This configuration requires a per-directory SSL renegotiation, since
the SSLVerifyClient is placed inside the <Directory> block. 
Unfortunately, it is a known issue that mod_ssl in httpd 2.0 cannot
perform per-directory renegotiations for requests with bodies (such as
POST or PUT). mod_ssl for 1.3 handled this by buffering the entire
POST body into memory; we are working on a better solution for 2.0.

For some sites/configurations, it is acceptable to work around this by
putting:

   SSLVerifyClient optional 

in the SSL vhost configuration, *outside* a directory block).  This
prompts the browser to send a client certificate in the initial SSL
handshake, if one is available.
Comment 4 Nicolai Schleifer 2004-05-19 11:24:16 EDT
Thanks for the help. I added your suggested option and I'm now waiting
for the customer triggered interaction. I will report about success
here next week at the earliest. Apologies for the 2nd/redundant sysreport.
Comment 5 Nicolai Schleifer 2004-06-18 05:25:05 EDT
It was not possible to achieve the desired solution: protecting a
directory on a https enabled server with a client certificate.

We tried your helpful advice and also rearragend the different options
in most thinkable ways. It was possible to access the entire directory
without any client certificate or authentication after inserting the
statement you suggestet. Everything happened in a quite
indeterministic way.

Finally we decided to ditch the requirement and protected the access
just by IP address. Very ugly, but like that we avoided the bug in httpd.

Unfortunately, since this is a production installation, we cannot play
around with it anymore or test other configurations. But it seems you
already have a way to reproduce this bug.

Comment 6 Joe Orton 2004-06-18 08:54:30 EDT
Sorry to hear you couldn't resolve the problem.  For future reference,
the configuration which is known to work is, e.g.:

<VirtualHost www.example.com:443>
   SSLEngine On
   ...
   SSLVerifyClient optional
</Virtual>

<Location /private>
   # Location which requires client certificate protection
   SSLVerifyClient require
</Location>

from your comments above it appears you may have omitted the
"SSLVerifyClient require" in the location context; apologies if my
comments mislead you there.
Comment 17 Joe Orton 2005-10-03 12:53:11 EDT
Experimental test packages are now available which contain the fix for this
issue.  These packages are unsupported and have not gone through the Red Hat QA
process.

  http://people.redhat.com/jorton/Taroon-httpd/

Any feedback from testing these packages is very welcome.
Comment 21 Joe Orton 2005-10-11 10:49:36 EDT
For tracking this bug against RHEL4, bug 170383 has been filed.  Experimental
RHEL4 test packages will be referenced from there shortly.
Comment 23 Julien Tognazzi 2005-10-26 08:41:26 EDT
(In reply to comment #17)
> Experimental test packages are now available which contain the fix for this
> issue.  These packages are unsupported and have not gone through the Red Hat QA
> process.
> 
>   http://people.redhat.com/jorton/Taroon-httpd/
> 
> Any feedback from testing these packages is very welcome.
> 
I add this very anoying bug, so I just installed these new RPMs.
So far, so good...

I'll tell you if I hit the problem again.

thanks
Comment 24 Julien Tognazzi 2005-10-26 08:43:11 EDT
(In reply to comment #17)
> Experimental test packages are now available which contain the fix for this
> issue.  These packages are unsupported and have not gone through the Red Hat QA
> process.
> 
>   http://people.redhat.com/jorton/Taroon-httpd/
> 
> Any feedback from testing these packages is very welcome.
> 
I had this very anoying bug, so I've just installed these new RPMs.
So far, so good...

I'll tell you if I hit the problem again.

thanks
Comment 31 Joe Orton 2006-01-09 11:38:39 EST
The fix for this issue was included in RHSA-2006-0159.  Thanks for the report.

http://rhn.redhat.com/errata/RHSA-2006-0159.html

Note You need to log in before you can comment on or make changes to this bug.