Bug 12355

Summary: POST incompatible w/ renegotiate https: connection
Product: Apache httpd-2 Reporter: samuel ball <sb>
Component: mod_sslAssignee: Apache HTTPD Bugs Mailing List <bugs>
Status: RESOLVED FIXED    
Severity: normal CC: apache+sender+041952, asf-bugzilla, cantor.2, cc.chen, chabrol, craig.stephen, dtoler, ers, geoffrey.w.halsted, gmeinusch, ian, jimrich, jkessel, m, mbertheau, ms.mouha, mxe20, nigel.green, phenyyoung, richard.heath, rob+apache, sergeyfd, Stephan.Uhde, wassa, will
Priority: P3 Keywords: PatchAvailable
Version: 2.5-HEAD   
Target Milestone: ---   
Hardware: PC   
OS: All   
Attachments: diff against httpd-2.0.48
patch for 2.0 to fix #12355
proposed fix
proposed fix for 2.0 branch
backport of patch from trunk
patch for 2.0.54

Description samuel ball 2002-09-06 10:19:56 UTC
when configuring SSLVerifyClient directive from global none to location 
require, php scripts inside location are no more able to receive post data. 

Error Method Not Allowed then occurs.
error log shows "[error] SSL Re-negotiation in conjunction with POST method not 
supported!" when SSLVerifyClient is set to 'required' but not when set to 'none'

this configuration inside ssl virtualhost section activate the bug :
----
SSLEngine on
SSLVerifyClient none
SSLVerifyDepth  1
SSLOptions +OptRenegotiate
<location /consultation/ >
        SSLVerifyClient require
</location>
----
this configuration does not activate the bug :
SSLEngine on
SSLVerifyClient require
SSLVerifyDepth  1
SSLOptions +OptRenegotiate
<location /consultation/ >
        SSLVerifyClient require
</location>
Comment 1 Joshua Slive 2002-10-17 02:35:23 UTC
[This is a mass bug update.]
This bug reports a problem in an older version of Apache 2.
Could you please update to the most recent version and see
if you can reproduce this problem.  If the bug still exists,
please update the bug with the latest version number.  If 
the bug no longer exists, please close the bug report.

Sorry for this impersonal response, but we get many more bug
reports than our volunteers can keep up with.
Thanks for using Apache!
Comment 2 Wolf-Dietrich Moeller 2002-10-23 13:36:40 UTC
This bug exists also in Apache/2.0.43 (WIN32) mod_ssl/2.8.11 OpenSSL/0.9.6g.
This bug appears when runnimg under both Windows NT4.0 and XP(NT5.1).
Comment 3 Wolf-Dietrich Moeller 2002-10-23 14:08:55 UTC
Addition to last comment:

Sorry, it must read Apache/2.0.43 (WIN32) mod_ssl/2.0.43 OpenSSL/0.9.6g
Comment 4 Marcin 2002-11-12 17:52:14 UTC
I observe the same bug with Apache 2.0.43 running on Linux 2.4.19 box, but 
with proprietary script handler. 
Comment 5 Pascal AUBRY 2002-11-13 10:19:32 UTC
Also observed on a Linux RedHat 8.0 (2.4.18-17 kernel) box running apache
2.0.43-1, mod_ssl-2.0.43-1 and php 4.2.2-8.

Comment 6 Sushil Kambampati 2003-02-20 18:11:58 UTC
After setting up SSL to require client authentication and importing the 
certificates into browsers, it works with Netscape 4.79 but not MSIE6 
(6.0.2800.1106.xpsp1.020828-1920).

The https error file says:
[error] SSL handshake failed (server myserver.com:443, client 192.168.1.2)
[error] SSL Library Error: 336105671 error:140890C7:lib(20):func(137):reason
(199)
The first time I also get the spurious SSL handshake interrupt message.

Server config:
Apache/2.0.43 (Unix) mod_ssl/2.0.43 OpenSSL/0.9.7 PHP/4.3.0
Kernel 2.4.8-26mdk
Comment 7 Eric Kraar 2003-04-08 17:10:39 UTC
When configured for client certificate authentication, POST method fails after
KeepAlive timeout - if KeepAlive is disabled, POST method always fails. 
SSLOptions +OptRenegotiate does not fix the problem.

Server: Apache/2.0.45 (Unix) mod_ssl/2.0.45 OpenSSL/0.9.7a
AIX 4.3.3

I have tested IE 5.5, Netscape 4.8, Netscape 7, and Mozilla 1.3 - All browsers
seem to be affected.  Log files can be found below.

IE 5.5 generates a segfault of the child and a 302 error along with the general
symptoms - details of this can be found in the logs below.

--------------------------------------------------------------------------------------------------
Configuration excerpts:

KeepAlive On
KeepAliveTimeout 15

SSLSessionCache dbm:/var/adm/httpd.ssl.cache
SSLSessionCacheTimeout 300
SSLMutex file:/var/adm/httpd.ssl.mutex

<Directory /docs/clientcert>
	SSLOptions +StdEnvVars +ExportCertData +OptRenegotiate
	SSLVerifyClient require
	SSLVerifyDepth 2
	SSLRequire %{SSL_CLIENT_CERT} eq file("<certfile>") \
		or %{SSL_CLIENT_CERT} eq file("<certfile>")
	Order Deny,Allow
	Deny from all
	Allow from 1.1.1.1
</Directory>

--------------------------------------------------------------------------------------------------
HTML files used for testing:

$ cat index.html
<HTML>
<BODY>
Hello client cert

<FORM action=index2.html method=post>
<INPUT value="Post to index2.html" type=submit>
</FORM>

</BODY>
</HTML>

$ cat index2.html
<HTML>
<BODY>
Hello client cert - index2

<FORM action=index.html method=post>
<INPUT value="Post to index.html" type=submit>
</FORM>

</BODY>
</HTML>

--------------------------------------------------------------------------------------------------
VH access log:
2.2.2.2 - - [07/Apr/2003:14:23:57 -0700] "GET /clientcert/index.html HTTP/1.1"
200 140 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3)
Gecko/20030312" GET /clientcert/index.html - "HTTP/1.1" (-)
2.2.2.2 - - [07/Apr/2003:14:24:03 -0700] "POST /clientcert/index2.html HTTP/1.1"
200 144 "https://test.domain.com/clientcert/index.html" "Mozilla/5.0 (Windows;
U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312" POST /clientcert/index2.html -
"HTTP/1.1" (-)
2.2.2.2 - - [07/Apr/2003:14:24:03 -0700] "POST /clientcert/index.html HTTP/1.1"
200 140 "https://test.domain.com/clientcert/index2.html" "Mozilla/5.0 (Windows;
U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312" POST /clientcert/index.html -
"HTTP/1.1" (-)
2.2.2.2 - - [07/Apr/2003:14:24:04 -0700] "POST /clientcert/index2.html HTTP/1.1"
200 144 "https://test.domain.com/clientcert/index.html" "Mozilla/5.0 (Windows;
U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312" POST /clientcert/index2.html -
"HTTP/1.1" (-)
2.2.2.2 - - [07/Apr/2003:14:24:05 -0700] "POST /clientcert/index.html HTTP/1.1"
200 140 "https://test.domain.com/clientcert/index2.html" "Mozilla/5.0 (Windows;
U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312" POST /clientcert/index.html -
"HTTP/1.1" (-)
2.2.2.2 - - [07/Apr/2003:14:24:06 -0700] "POST /clientcert/index2.html HTTP/1.1"
200 144 "https://test.domain.com/clientcert/index.html" "Mozilla/5.0 (Windows;
U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312" POST /clientcert/index2.html -
"HTTP/1.1" (-)
2.2.2.2 - - [07/Apr/2003:14:24:07 -0700] "POST /clientcert/index.html HTTP/1.1"
200 140 "https://test.domain.com/clientcert/index2.html" "Mozilla/5.0 (Windows;
U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312" POST /clientcert/index.html -
"HTTP/1.1" (-)
2.2.2.2 - - [07/Apr/2003:14:25:12 -0700] "POST /clientcert/index2.html HTTP/1.1"
405 244 "https://test.domain.com/clientcert/index.html" "Mozilla/5.0 (Windows;
U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312" POST /clientcert/index2.html -
"HTTP/1.1" (-)

VH error log:
[Mon Apr 07 14:25:12 2003] [error] SSL Re-negotiation in conjunction with POST
method not supported!
hint: try SSLOptions +OptRenegotiate

--------------------------------------------------------------------------------------------------
With Internet Explorer 5.5:

VH access log:
2.2.2.2 - - [07/Apr/2003:15:46:15 -0700] "GET /clientcert/ HTTP/1.1" 302 227 "-"
"Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; T312461)" GET /clientcert/ -
"HTTP/1.1" (-)
2.2.2.2 - - [07/Apr/2003:15:46:16 -0700] "GET /clientcert/ HTTP/1.1" 200 140 "-"
"Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; T312461)" GET
/clientcert/index.html - "HTTP/1.1" (-)
2.2.2.2 - - [07/Apr/2003:15:46:24 -0700] "POST /clientcert/index2.html HTTP/1.1"
200 144 "https://test.domain.com/clientcert/" "Mozilla/4.0 (compatible; MSIE
5.5; Windows NT 5.0; T312461)" POST /clientcert/index2.html - "HTTP/1.1" (-)
2.2.2.2 - - [07/Apr/2003:15:46:25 -0700] "POST /clientcert/index.html HTTP/1.1"
200 140 "https://test.domain.com/clientcert/index2.html" "Mozilla/4.0
(compatible; MSIE 5.5; Windows NT 5.0; T312461)" POST /clientcert/index.html -
"HTTP/1.1" (-)
2.2.2.2 - - [07/Apr/2003:15:46:26 -0700] "POST /clientcert/index2.html HTTP/1.1"
200 144 "https://test.domain.com/clientcert/index.html" "Mozilla/4.0
(compatible; MSIE 5.5; Windows NT 5.0; T312461)" POST /clientcert/index2.html -
"HTTP/1.1" (-)
2.2.2.2 - - [07/Apr/2003:15:46:27 -0700] "POST /clientcert/index.html HTTP/1.1"
200 140 "https://test.domain.com/clientcert/index2.html" "Mozilla/4.0
(compatible; MSIE 5.5; Windows NT 5.0; T312461)" POST /clientcert/index.html -
"HTTP/1.1" (-)
2.2.2.2 - - [07/Apr/2003:15:46:28 -0700] "POST /clientcert/index2.html HTTP/1.1"
200 144 "https://test.domain.com/clientcert/index.html" "Mozilla/4.0
(compatible; MSIE 5.5; Windows NT 5.0; T312461)" POST /clientcert/index2.html -
"HTTP/1.1" (-)
2.2.2.2 - - [07/Apr/2003:15:46:29 -0700] "POST /clientcert/index.html HTTP/1.1"
200 140 "https://test.domain.com/clientcert/index2.html" "Mozilla/4.0
(compatible; MSIE 5.5; Windows NT 5.0; T312461)" POST /clientcert/index.html -
"HTTP/1.1" (-)
2.2.2.2 - - [07/Apr/2003:15:46:58 -0700] "POST /clientcert/index2.html HTTP/1.1"
405 244 "https://test.domain.com/clientcert/index.html" "Mozilla/4.0
(compatible; MSIE 5.5; Windows NT 5.0; T312461)" POST /clientcert/index2.html -
"HTTP/1.1" (-)

VH error log:
[Mon Apr 07 15:46:15 2003] [error] Re-negotiation handshake failed: Not accepted
by client!?
[Mon Apr 07 15:46:58 2003] [error] SSL Re-negotiation in conjunction with POST
method not supported!
hint: try SSLOptions +OptRenegotiate

Server error log:
[Mon Apr 07 15:46:16 2003] [notice] child pid 28262 exit signal Segmentation
fault (11)
Comment 8 Matthias Wimmer 2003-05-12 22:36:45 UTC
The existance of this "bug" is documented in modules/ssl/ssl_engine_kernel.c
line 525. But it would really be nice to reimplement this feature.
Comment 9 keilh 2003-12-18 12:33:22 UTC
Created attachment 9626 [details]
diff against httpd-2.0.48
Comment 10 keilh 2003-12-18 12:46:15 UTC
Fixed the problem in the following way:
Before the renegotiation is starting the body of the POST request
will be readed via ap_get_client_block().(So content-length, chunking etc.
is handeld correctly.) 
The data will be stored in a brigade and an input filter
will be added just after the http_header_filter. That input filter has the
data from it's ctx. 
So in any subsequent read call that input filter will be invoked and 
can return the stored data.


P.S. Im not sure if the upload of the diff is ok, so I paste it to be sure


*** mod_ssl.h.patched	Thu Dec 18 13:11:48 2003
--- mod_ssl.h	Thu Dec 18 13:13:19 2003
***************
*** 709,714 ****
--- 709,715 ----
  void         ssl_io_filter_init(conn_rec *, SSL *);
  void         ssl_io_filter_register(apr_pool_t *);
  long         ssl_io_data_cb(BIO *, int, MODSSL_BIO_CB_ARG_TYPE *, int, long,
long);
+ long         ssl_io_suck(request_rec *);
  
  /*  PRNG  */
  int          ssl_rand_seed(server_rec *, apr_pool_t *, ssl_rsctx_t, char *);
*** ssl_engine_kernel.c.patched	Thu Dec 18 13:11:39 2003
--- ssl_engine_kernel.c	Thu Dec 18 13:15:04 2003
***************
*** 583,596 ****
       *
       * !! BUT ALL THIS IS STILL NOT RE-IMPLEMENTED FOR APACHE 2.0 !!
       */
!     if (renegotiate && !renegotiate_quick && (r->method_number == M_POST)) {
          ap_log_error(APLOG_MARK, APLOG_ERR, 0, r->server,
                       "SSL Re-negotiation in conjunction "
                       "with POST method not supported!\n"
                       "hint: try SSLOptions +OptRenegotiate");
! 
          return HTTP_METHOD_NOT_ALLOWED;
      }
  
      /*
       * now do the renegotiation if anything was actually reconfigured
--- 583,602 ----
       *
       * !! BUT ALL THIS IS STILL NOT RE-IMPLEMENTED FOR APACHE 2.0 !!
       */
! 	if (renegotiate && !renegotiate_quick && (r->method_number == M_POST)) {
! #ifdef SSL_CONSERVATIVE 		
          ap_log_error(APLOG_MARK, APLOG_ERR, 0, r->server,
                       "SSL Re-negotiation in conjunction "
                       "with POST method not supported!\n"
                       "hint: try SSLOptions +OptRenegotiate");
! 		
          return HTTP_METHOD_NOT_ALLOWED;
+ #else		
+ 		if( ssl_io_suck(r) != OK) {
+ 			return HTTP_METHOD_NOT_ALLOWED;
+ 		}
      }
+ #endif /* SSL_CONSERVATIVE */
  
      /*
       * now do the renegotiation if anything was actually reconfigured
*** ssl_engine_io.c.patched	Thu Dec 18 13:12:02 2003
--- ssl_engine_io.c	Thu Dec 18 13:21:31 2003
***************
*** 897,902 ****
--- 897,987 ----
  }
  
  static const char ssl_io_filter[] = "SSL/TLS Filter";
+ static const char ssl_buff_filter[] = "SSL/TLS Buffering Filter";
+ /*
+  * reads the buffered data during a POST request with renegotiation
+  * will be registere at runtime.
+  * NOTE: we try to buffer the complete body. Use the attribute
'LimitRequestBody'
+  * preventing DOS attacks.
+  */
+ long ssl_io_suck(request_rec *r)
+ {
+ 	apr_bucket *bucket;
+ 	apr_bucket_brigade *bb =
apr_brigade_create(r->pool,r->connection->bucket_alloc);
+ 
+ 	int readed = 0;
+ 	int len = 0;
+ 	int toRead= 0;
+ 	char *buffer = NULL;
+ 	char *pos = NULL;
+ 	
+ 	if(ap_setup_client_block(r,REQUEST_CHUNKED_DECHUNK) !=OK) {
+ 		return HTTP_METHOD_NOT_ALLOWED; 
+ 	}
+ 
+ 	if(!ap_should_client_block(r)) {
+ 		return OK;
+ 	}
+ 	
+ 	do {
+ 		buffer = apr_pcalloc(r->pool,HUGE_STRING_LEN);
+ 		toRead = HUGE_STRING_LEN;
+ 
+ 		/* check malloc */
+ 		if(buffer == NULL) {
+ 			ap_log_error(APLOG_MARK, APLOG_ERR, 0, r->server,
+                      "SSL Re-negotiation in conjunction "
+ 				     "with POST (buffering body failed)!\n");
+ 			apr_brigade_destroy(bb);
+ 			return HTTP_METHOD_NOT_ALLOWED;			
+ 		}
+ 		
+ 		/* fill the bucket */
+ 		pos = buffer;
+ 		len = 0;
+ 		do {
+ 			readed  = ap_get_client_block(r,pos,toRead);
+ 
+ 			if(readed <=0) {
+ 				break;
+ 			}
+ 			
+ 			toRead  -= readed;
+ 			
+ 			/* sanity */
+ 			if(toRead<0) {
+ 				return HTTP_METHOD_NOT_ALLOWED;
+ 			}
+ 
+ 			pos += readed;
+ 			len += readed;	
+ 		}
+ 		while(toRead>0);
+ 
+ 		/* check last read result */
+ 		if(readed<0) {
+ 			ap_log_error(APLOG_MARK, APLOG_ERR, 0, r->server,
+                      "SSL Re-negotiation in conjunction "
+ 				     "with POST (reading body failed)!\n");
+ 			apr_brigade_destroy(bb);
+ 			return HTTP_METHOD_NOT_ALLOWED; 
+ 		}
+ 		
+ 		/* check if we have readed everything */
+ 		if(len == 0) {
+ 			break;
+ 		}
+ 		bucket =
apr_bucket_pool_create(buffer,len,r->pool,r->connection->bucket_alloc);
+ 		
+         APR_BRIGADE_INSERT_TAIL(bb, bucket);
+ 	} 
+ 	while(1);
+ 	
+ 	//add the ssl_buff_filter_input
+ 	ap_add_input_filter(ssl_buff_filter, bb, r, r->connection);
+ 	
+ 	return OK;									  
+ }
  
  /*
   *  Close the SSL part of the socket connection
***************
*** 1361,1366 ****
--- 1446,1529 ----
      return status;
  }
  
+ static apr_status_t ssl_buff_filter_input(ap_filter_t *f,
+                                         apr_bucket_brigade *bb,
+                                         ap_input_mode_t mode,
+                                         apr_read_type_e block,
+                                         apr_off_t readbytes)
+ {
+ 	apr_bucket_brigade *aa = f->ctx;
+ 	apr_status_t  rv;
+ 	
+ 	if(aa && !APR_BRIGADE_EMPTY(aa)) {
+ 
+ 		if(mode == AP_MODE_READBYTES) {
+ 			apr_bucket *b;
+ 			apr_off_t missing = readbytes;
+ 			apr_size_t len;
+ 			const char *tmp;
+ 	
+ 			while (!APR_BRIGADE_EMPTY(aa)) {
+ 				b = APR_BRIGADE_FIRST(aa);
+ 			
+ 				rv = apr_bucket_read(b, &tmp, &len, APR_BLOCK_READ);
+ 				if (rv != APR_SUCCESS) {
+ 					return rv;
+ 				}
+ 				
+ 				/* consume whole bucket */
+ 				if(missing >= len) {
+ 					APR_BUCKET_REMOVE(b);
+ 					APR_BRIGADE_INSERT_TAIL(bb,b);
+ 				}
+ 				/* comsume only a part */ 
+ 				else{
+ 					rv = apr_bucket_split(b, missing);
+ 					if (rv != APR_SUCCESS) {
+ 						return rv;
+ 					}
+ 					
+ 					APR_BUCKET_REMOVE(b);
+ 					APR_BRIGADE_INSERT_TAIL(bb, b);
+ 					break;
+ 				}
+ 				
+ 				missing -= len;
+ 				
+ 				if (missing = 0) {
+ 					break;
+ 				}
+ 
+ 				if(missing<0) {
+ 					return AP_FILTER_ERROR;
+ 				}
+ 			}
+ 			return APR_SUCCESS;
+ 		}
+ 		else if (mode == AP_MODE_READBYTES) {
+ 			apr_bucket_brigade *nb = apr_brigade_create(f->r->pool,f->c->bucket_alloc);
+ 			
+ 			/* split */
+ 			rv = apr_brigade_split_line(nb,aa,block,readbytes);
+ 			if( rv != APR_SUCCESS) {				
+ 				return rv;
+ 			} 
+ 
+ 			/* concatinate */
+ 			APR_BRIGADE_CONCAT(bb,aa);
+ 			
+ 			/* remember the rest */
+ 			f->ctx = nb;
+ 			
+ 			return APR_SUCCESS;	
+ 		}
+ 		
+ 	}
+ 	
+ 	
+ 	return ap_pass_brigade(f->next, bb);
+ }
+ 
  static void ssl_io_input_add_filter(ssl_filter_ctx_t *filter_ctx, conn_rec *c,
                                      SSL *ssl)
  {
***************
*** 1417,1422 ****
--- 1580,1586 ----
  {
      ap_register_input_filter  (ssl_io_filter, ssl_io_filter_input,  NULL,
AP_FTYPE_CONNECTION + 5);
      ap_register_output_filter (ssl_io_filter, ssl_io_filter_output, NULL,
AP_FTYPE_CONNECTION + 5);
+     ap_register_input_filter  (ssl_buff_filter, ssl_buff_filter_input,  NULL,
AP_FTYPE_PROTOCOL - 1);
      return;
  }
  

 
Comment 11 Erik Abele 2003-12-18 12:55:21 UTC
Just adding the PatchAvailable keyword. Hartmut, to keep bugs in the loop please don't resolve 
them as fixed until they're reviewed and/or committed at least to one dev-tree. Anyway, thanks for 
the patch.
Comment 12 Mohamed Sadok MOUHA 2003-12-26 10:30:15 UTC
Also, this configuration does not activate the bug :
SSLEngine on
SSLVerifyClient optional
SSLOptions +OptRenegotiate
<location /location/ >
        SSLVerifyClient optional
        SSLVerifyDepth 10
</location>
Comment 13 Rob Riggs 2004-02-09 01:27:21 UTC
I was having a similar problem with per-directory SSL authentication with DAV.
(Note that the patch posted earlier does not fix the problem for DAV.)

I have worked around the problem by having a global "SSLVerifyClient optional"
directive.  The per-directory "SSLVerifyClient required" is then processed
properly.  This seems to preserve all of the behavior that I need.  Those
without a certificate can still access the site via SSL, and the entire site,
including the portions using SSL authentication, work for those with proper
certificates. This may need no more than clarification in the documentation.
Comment 14 William J Dennison 2004-02-09 15:47:29 UTC
I have attempted usage of all posts in this bug to date.  I have used the patch,
no dice.  I have altered my configurations as noted by the posts mentioning that
the bug will not be enabled with a configuration change, again no dice.  I have
also used several configurations noted in errors by the apache software and
nothing works.  I always get "SSL Re-negotiation in conjunction with POST method
not supported!" when the SSL is renegotiated and the next method is a POST
instead of a GET.

I find it hard to swallow ("because I am a huge fan of Apache and mod_ssl"),
that Apache organization would make such a glaring flaw in the 2.0 builds
considering all this worked great in the 1.3 builds.  My final resolution
because I am in a production environment (until Apache org. fixes the problem).
 Go back to the 1.3 build ASAP.
Comment 15 Birger Toedtmann 2004-02-09 16:06:51 UTC
Hello,

I also applied all "remedies" so far mentioned by others (including patching), 
to no avail, the problem is still alive and healthy.  As a consequence, we are 
considering going back to 1.3 as well.  I'm reluctant to go in this direction, 
but without progress for months now, there seems to be no perspective for 2.0 
within environments requiring client certs and the POST method....

BTW: You should remove the "PatchAvailable" keyword.  No offense for the creator 
of the patch, but it simply doesn't work.


Regards,

Birger
Comment 16 Joe Orton 2004-05-27 10:40:07 UTC
*** Bug 21167 has been marked as a duplicate of this bug. ***
Comment 17 Joe Orton 2004-05-27 13:14:45 UTC
Created attachment 11681 [details]
patch for 2.0 to fix #12355
Comment 18 Joe Orton 2004-05-27 13:18:28 UTC
*Experimental* patch attached above for 2.0, this is closer to fixing the issue
properly, without buffering the entire request body in memory.  (it makes one
bogus assumption about the filter interfaces but seems to work OK)  This
approach also needs careful checking bugs may allow clients to bypass the access
control checks.
Comment 19 Joe Orton 2004-06-03 09:02:32 UTC
Created attachment 11736 [details]
proposed fix
Comment 20 Joe Orton 2004-06-03 09:10:03 UTC
Second patch attached is the fix I have proposed for this issue, which has no
issues that I'm currently aware of, and could do with some wider testing.
Comment 21 Joe Orton 2004-06-03 09:11:56 UTC
*** Bug 18395 has been marked as a duplicate of this bug. ***
Comment 22 Joe Orton 2004-06-03 12:03:27 UTC
Created attachment 11745 [details]
proposed fix for 2.0 branch
Comment 23 Joe Orton 2004-06-03 12:05:36 UTC
Proposed patch, rediffed for 2.0, attached above.
Comment 24 Birger Toedtmann 2004-06-05 10:36:23 UTC
Hi,

when patching the apache2-2.0.48 source RPM for Mandrake 10 (and 
rebuilding the binaries), the SSL service crashes immediately upon
the use of client certificates:

[Sat Jun 05 12:30:50 2004] [notice] LDAP: Built with OpenLDAP LDAP SDK
[Sat Jun 05 12:30:50 2004] [notice] Digest: generating secret for digest
authentication ...
[Sat Jun 05 12:30:50 2004] [notice] Digest: done
[Sat Jun 05 12:30:51 2004] [notice] Apache-AdvancedExtranetServer/2.0.48
(Mandrake Linux/6.2.100mdk) mod_ssl/2.0.48 OpenSSL/0.9.7a DAV/2 PHP/4.3.1
configured -- resuming normal operations

 - service is now working and delivers ordinary pages successfully,
   including PHP and MySQL_over_PHP operations and SSL (without client
   certs) -

[Sat Jun 05 12:32:21 2004] [notice] child pid 29488 exit signal Segmentation
fault (11)

 - that was the child that dealt the first time with a 
   client certificate -


Without the patch (but same source) and without using POST, the 
site works "perfectly" using client certificates.




Birger
Comment 25 Joe Orton 2004-07-07 14:09:26 UTC
*** Bug 29569 has been marked as a duplicate of this bug. ***
Comment 26 Joe Orton 2004-07-08 14:31:20 UTC
Please don't mark bugs as fixed without adding a comment, and please don't mark
bugs as fixed if they aren't really fixed!
Comment 27 David A. Desrosiers 2004-08-17 18:03:38 UTC
Have there been any updates on this issue since the last comment filed on July
8th of this year? 
Comment 28 Joe Orton 2004-08-23 20:18:59 UTC
No; I'm not really convinced the solution I was working on can be made to be secure.

Note that for many configurations, there is a simple workaround: add

  SSLVerifyClient optional

to the SSL vhost config, as well as the "SSLVerifyClient require" in whatever
Location/Directory context.
Comment 29 Joe Orton 2004-08-24 14:18:07 UTC
I was reminded privately that the other workaround for this bug is of course to
ensure that the first access the browser makes to the SSLVerifyClient-protected
location uses a GET request rather than a POST request.
Comment 30 Joe Orton 2004-09-22 10:20:14 UTC
*** Bug 31314 has been marked as a duplicate of this bug. ***
Comment 31 William A. Rowe Jr. 2004-12-26 17:31:45 UTC
Some general comments;

HTTP/1.0

  the 'classic' HTTP/1.0 handling -must- buffer the body if the connection
  will be renegotiated.  This should no longer be handled inside the mod_ssl
  module itself, by itself.  With the advent of filters, either apreq2 or
  another 'client buffer' module must be implemented.  The logic looks like;

    brigade read loop
      mem_body > max_memory_body ?
        create tmpfile if tmpfile isnull
        response 'failure' if total_body > max_buffer_body
        write body -> tmpfile
    reopen tmpfile read-only
    insert tmpfile bucket of tmpfile prior to remaining mem_body buckets.

  now we have two controls that would prevent DoS attacks present in the
  original fix proposed (unbounded growth of the body.)  Remember, the
  renegotiation would NOT determine the client certificate is valid until
  after these resources had been consumed by a nefarious client.

  I rather like the idea of apreq2 doing this work, and actually, integrating
  apreq2 as a 'stock' apache module.  apreq2 does nothing until some module
  in the server configuration wants to use its services.

HTTP/1.1 + client Expect: 100-continue

  http://rfc.net/rfc2616.html#s8.2.3

  Clients which truly pause for 100-continue could be satisfied with no
  buffering of the body.  Schedule the renegotation prior to sending the
  100 CONTINUE response.

Finally note that this is not specific to POST, it's generic to all HTTP
methods which contain a client body.  The headers may be inspected to
determine if the client is attempting to push a body with the request.

Comment 32 Marc Stern 2005-04-25 15:26:38 UTC
Isn't there any way to suppress renegotiation ?
Comment 33 Bruno Santiago 2005-05-13 21:59:09 UTC
Workaround!!!

Following configuration works fine (optional for any except with CA 
certificate, and required to an especific location):

SSLEngine on
SSLVerifyClient optional_no_ca
SSLVerifyDepth  2
SSLOptions +OptRenegotiate
<location /any_location/ >
        SSLVerifyClient require
</location>

Regards,

Bruno Santiago
Comment 34 Marc Stern 2005-05-31 11:57:55 UTC
"SSLVerifyClient optional" seems also safe.
Is "SSLOptions +OptRenegotiate" really needed, or is it an optimisation ?
Is it totally safe ? The doc states to use this carefully.
Comment 35 Yefym 2005-08-30 11:17:46 UTC
(In reply to comment #34)
> "SSLVerifyClient optional" seems also safe.
> Is "SSLOptions +OptRenegotiate" really needed, or is it an optimisation ?
> Is it totally safe ? The doc states to use this carefully.


The workaround explained above is not safe at least for apache 2.0.52.
"
RE: [users@httpd] Bug or Feature : global SSLVerifyClient in <VirtualHost>
overrides the same in  <Location>?

Simple test scenario is :
1. access document root location - "SSLVerifyClient optional" ,  cancel
certificate choice window.
2. access location <Location "/auth"> with  "SSLVerifyClient require" - no
triggered SSL negotiation - access without certificate granted.

Correct should be the following behaviour, but there is no re-negotiation:
>SSLVerifyClient is documented as working in directory context, so it should
also work in <Location> context. The manual page for mod_ssl does 
>explicitly say that a SSL renegotiation is triggered if a request for the
location is received.
 

config sample:

<VirtualHost> 
SSLVerifyClient optional 

Alias /auth   /htdocs/access 
<Location "/access"> 
SSLVerifyClient require 
SSLOptions +ExportCertData +StdEnvVars +OptRenegotiate
SSLVerifyDepth 5 
Options None 
</Location> 

</VirtualHost> 

"





Comment 36 Yefym 2005-08-30 11:33:56 UTC
Proposed workaround is to add an additional <VirtualHost> and 
configure in its context SSLVerifyClient require.


In my particular case creating webapi virtualhost suppose to fix problems with axis.









Comment 37 Joe Orton 2005-08-31 16:44:47 UTC
The problem mentioned in comment 35 is a separate issue from the bug covered
here, and is fixed by: http://svn.apache.org/viewcvs?rev=264800&view=rev
Comment 38 Marc Poulhi 2005-09-01 13:25:05 UTC
I was told to use something like this:

<VirtualHost ...>
   ...
   SSLVerifyClient none
   ...
   <Location /plop>
      ...
      SSLVerifyClient require
      ...
   </Location>
</VirtualHost>

And this seems to work fine. Can someone confirm this is working correctly and
I'm not missing some "feature" for this bug ?
Thanks
Comment 39 Scott Cantor 2005-09-01 16:22:02 UTC
If the bug isn't fixed, the issue is that the Location-specific renegotiation
fails on a POST. If you're testing with GET, that's not a useful test.
Comment 40 Joe Orton 2005-09-22 20:38:06 UTC
Created attachment 16491 [details]
backport of patch from trunk

This is a backport of the patch from the trunk which was committed to fix this
issue.	Any results from testing are welcome.
Comment 41 Joe Orton 2005-09-23 09:24:09 UTC
Created attachment 16495 [details]
patch for 2.0.54

This patch can be applied to 2.0.54.
Comment 42 Joe Orton 2005-09-28 13:00:20 UTC
Now fixed for 2.1.8-beta and later.

http://svn.apache.org/viewcvs?rev=290965&view=rev

Given sufficient testing of the patch from comment 41, this could get a backport
to 2.0.x.
Comment 43 Ralph Seichter 2005-10-18 19:34:09 UTC
(In reply to comment #41)

> This patch can be applied to 2.0.54.

The patch can be applied to 2.0.55 aswell, and it allows using the
following setup:

  SSLVerifyClient optional
  <Location /subversion>
    DAV svn
    SVNParentPath /path/to/reps
    AuthzSVNAccessFile /path/to/accessfile
    SSLVerifyClient require
    SSLUserName SSL_CLIENT_S_DN_CN
    SSLOptions +StrictRequire
  </Location>

I used Subversion 1.2.3 clients on Linux and Windows for successful
testing.

It is important to note that with the above configuration, access to
the Subversion repository requires a client certificate, while other
areas of the server can be accessed without certificates (i.e. webmail
via HTTPS). Judging from my tests, this desired behaviour can not be
achieved based on vanilla 2.0.55 sources, so I strongly welcome Joe's
patch and hope it will be included as a 2.0.x backport in the future.
Comment 44 Yefym 2006-03-20 09:00:51 UTC
(In reply to comment #43)
> (In reply to comment #41)
> 
> > This patch can be applied to 2.0.54.
> 
> The patch can be applied to 2.0.55 aswell, and it allows using the
> following setup:
> 
>   SSLVerifyClient optional
>   <Location /subversion>
>     DAV svn
>     SVNParentPath /path/to/reps
>     AuthzSVNAccessFile /path/to/accessfile
>     SSLVerifyClient require
>     SSLUserName SSL_CLIENT_S_DN_CN
>     SSLOptions +StrictRequire
>   </Location>
> 
> I used Subversion 1.2.3 clients on Linux and Windows for successful
> testing.
> 
> It is important to note that with the above configuration, access to
> the Subversion repository requires a client certificate, while other
> areas of the server can be accessed without certificates (i.e. webmail
> via HTTPS). Judging from my tests, this desired behaviour can not be
> achieved based on vanilla 2.0.55 sources, so I strongly welcome Joe's
> patch and hope it will be included as a 2.0.x backport in the future.



The problem is still not fixed. Was tested for apache 2.0.55 :
there is still post method not allowed message described by you and other guys
in this topic.

After patching apache it still doesn`t work, only the message is different.


We tried with apache_2.0.55 with unofficial patch from bugzilla (No.:12355) and
got the following messages in logfiles.

access_log:

85.115.6.202 - - [17/Mar/2006:13:13:50 +0000] "POST
/webservice/services/SessionManagement HTTP/1.0" 403 - "-"
 "-"

error_log with debug level in http.conf:

[Fri Mar 17 13:32:54 2006] [debug] ssl_engine_kernel.c(1738): OpenSSL:
Handshake: start
[Fri Mar 17 13:32:54 2006] [debug] ssl_engine_kernel.c(1746): OpenSSL: Loop: SSL
renegotiate ciphers
[Fri Mar 17 13:32:54 2006] [debug] ssl_engine_kernel.c(1746): OpenSSL: Loop:
SSLv3 write hello request
A
[Fri Mar 17 13:32:54 2006] [debug] ssl_engine_kernel.c(1746): OpenSSL: Loop:
SSLv3 flush data
[Fri Mar 17 13:32:54 2006] [debug] ssl_engine_kernel.c(1746): OpenSSL: Loop:
SSLv3 write hello request
C
[Fri Mar 17 13:32:54 2006] [info] Awaiting re-negotiation handshake
[Fri Mar 17 13:32:54 2006] [debug] ssl_engine_kernel.c(1738): OpenSSL:
Handshake: start
[Fri Mar 17 13:32:54 2006] [debug] ssl_engine_kernel.c(1746): OpenSSL: Loop:
before accept initializati
on
[Fri Mar 17 13:32:54 2006] [debug] ssl_engine_io.c(1697): OpenSSL: read 0/5
bytes from BIO#83a24b8 [mem
: 842d708] (BIO dump follows)
[Fri Mar 17 13:32:54 2006] [debug] ssl_engine_io.c(1644):
+--------------------------------------------
-----------------------------+
[Fri Mar 17 13:32:54 2006] [debug] ssl_engine_io.c(1675):
+--------------------------------------------
-----------------------------+
[Fri Mar 17 13:32:54 2006] [debug] ssl_engine_kernel.c(1770): OpenSSL: Exit:
failed in SSLv3 read clien
t hello B
[Fri Mar 17 13:32:54 2006] [error] Re-negotiation handshake failed: Not accepted
by client!?
[Fri Mar 17 13:32:54 2006] [debug] ssl_engine_io.c(1488): [client 85.115.6.202]
read from buffered SSL
brigade, mode 0, 8192 bytes
[Fri Mar 17 13:32:54 2006] [debug] ssl_engine_io.c(1550): [client 85.115.6.202]
buffered SSL brigade no
w exhausted; removing filter
[Fri Mar 17 13:33:07 2006] [debug] ssl_engine_io.c(1708): OpenSSL: I/O error, 5
bytes expected to read
on BIO#83a24b8 [mem: 842d708]
[Fri Mar 17 13:33:07 2006] [info] (70007)The timeout specified has expired: SSL
input filter read faile
d.
[Fri Mar 17 13:33:07 2006] [debug] ssl_engine_kernel.c(1756): OpenSSL: Write:
SSL negotiation finished
successfully
[Fri Mar 17 13:33:07 2006] [info] Connection to child 2 closed with standard
shutdown(server drecord.de
.something.com:443, client 85.115.6.202)

--------------------------------------------------------------------------------


P.S.
We have additional virtualhost configured that is responsible for certificate
authentication and session management with axis, there it works perfectly. So
the problem occures only for <location> that doesn`t have a globaly set
<SSLVerifyClient> to optional or required

P.P.S. 
<SSLVerifyClient> optional in a global context fix the problem , but this
solution is not acceptable because it enforce the browser to show the popup with
installed certificates.(sure it is a browser issue and probably could be
configured on the client side, but this is not the way it should work in
productive env.)

Regards, Yefym
Comment 45 Joe Orton 2006-03-30 09:19:59 UTC
If you have any problems using this patch, please upgrade to 2.2.0 instead, and
file bugs giving the error_log output from 2.2.0.
Comment 46 Ruediger Pluem 2006-03-30 21:16:14 UTC
*** Bug 39154 has been marked as a duplicate of this bug. ***
Comment 47 Ruediger Pluem 2006-04-07 23:12:59 UTC
*** Bug 39243 has been marked as a duplicate of this bug. ***
Comment 48 Ruediger Pluem 2006-06-02 22:54:42 UTC
*** Bug 39705 has been marked as a duplicate of this bug. ***
Comment 49 richard chen 2006-06-05 07:38:12 UTC
I couldn't understand why this bug is not fix by Apache team since the release 
of Apache2. I really need this features to be enabled as what we have in 
mod_ssl for version for apache1.3.x.
Comment 50 Ruediger Pluem 2006-06-05 11:37:11 UTC
It is fixed in 2.2.x, but has not been backported to 2.0.x yet. There is a patch
against 2.0.54 attached to this report for those who need to fix this
immediately for 2.0.x.
Comment 51 William A. Rowe Jr. 2006-07-23 04:48:06 UTC
  First this IS fixed in 2.2.0.  Backports aren't discussed on Bugzilla, this
  issue has been raised in our 2.0.x STATUS file.  And given a more accurate name.
Comment 52 Derrier Dominique 2007-04-14 00:29:25 UTC
this bug is always present with Apache/2.2.4.

You can't mixed SSLVerifyClient optinal and SSLVerifyClient requierd part
To allow some Location for non SSL valid Client.


NOT WORKING ========
------------------------
SSLVerifyClient optional
SSLVerifyDepth  1
SSLOptions +OptRenegotiate
<Location /Album>
SSLRequireSSL
SSLVerifyClient      require
SSLCACertificateFile conf/ssl.crt/Root_Certificat.crt
SSLCACertificatePath conf/ssl.crt
SSLRequire  (%{SSL_CLIENT_S_DN_OU} eq "Portable" || %{SSL_CLIENT_S_DN_OU} eq
"Personnal")
SSLVerifyDepth       3
#FIX ANOTHER BUG
SetEnv REMOTE_USER ${SSL_CLIENT_S_DN_CN}
SSLUserName SSL_CLIENT_S_DN_CN
</location>


WORKING ==
---------
Comment 53 Derrier Dominique 2007-04-14 00:42:32 UTC
Sorry ... I forgot to say .. that the bug is only with php.
CGI perl work fine ..
Comment 54 Derrier Dominique 2007-04-15 01:35:43 UTC
It's working fine when the certificat private key is <= 512.
2048b not working
1024b not working.
But I don't understand why

If it's can help coders.
Comment 55 Davi Arnaut 2007-06-08 09:59:40 UTC
(In reply to comment #54 and previous ones)
> It's working fine when the certificat private key is <= 512.
> 2048b not working
> 1024b not working.
> But I don't understand why
> 
> If it's can help coders.
> 

This looks like an unrelated problem, could you open a new issue for it? Thanks.
Comment 56 Davi Arnaut 2007-06-08 11:55:40 UTC
(In reply to comment #52)
> this bug is always present with Apache/2.2.4.
> 
> You can't mixed SSLVerifyClient optinal and SSLVerifyClient requierd part
> To allow some Location for non SSL valid Client.
> 

This was fixed in Apache 2.0.55, changelog:

  *) SECURITY: CVE-2005-2700 (cve.mitre.org)
     mod_ssl: Fix a security issue where "SSLVerifyClient" was not
     enforced in per-location context if "SSLVerifyClient optional"
     was configured in the vhost configuration.  [Joe Orton]
Comment 57 Ruediger Pluem 2007-06-10 03:02:23 UTC
*** Bug 42625 has been marked as a duplicate of this bug. ***
Comment 58 Serge Dubrouski 2007-06-10 18:47:26 UTC
*** Bug 42625 has been marked as a duplicate of this bug. ***
Comment 59 Ruediger Pluem 2007-07-17 12:22:37 UTC
Backported to 2.0.x as r536373
(http://svn.apache.org/viewvc?view=rev&revision=536373)