Re: SSLUseStapling: ssl handshake fails until httpd restart

[Kaspar Brand]

On 01.10.2015 16:32, Reindl Harald wrote:
> Am 01.10.2015 um 16:29 schrieb Plüm, Rüdiger, Vodafone Group:
>> The question is: What happens on Firefox side. Of course it still tries to 
>> get to the OCSP server, but it should not cause an error on Firefox side if 
>> this does not work.
> 
> no, it does not because "security.OCSP.enabled = 0" and i saw at least 
> two requests to different servers failing with my Firefox with the 
> responder error from the webserver

What do you have security.OCSP.require set to? If it's "true" (a setting
no longer configurable through the UI, BTW, see
https://bugzilla.mozilla.org/show_bug.cgi?id=1034360), then Firefox
shows a fairly peculiar behavior: even when OCSP checking is disabled
(by setting security.OCSP.enabled to "0", through the "Query OCSP
responder servers to confirm the current validity of certificates"
preference in the UI under Advanced -> Certificates), it still includes
a status_request extension in the TLS handshake, and will subsequently
fail when it receives a stapled tryLater OCSP response, as long as
security.OCSP.require=true.

Kaspar

Re: SSLUseStapling: ssl handshake fails until httpd restart

[Reindl Harald]

Am 03.10.2015 um 11:16 schrieb Kaspar Brand:

On 01.10.2015 16:32, Reindl Harald wrote:

Am 01.10.2015 um 16:29 schrieb Plüm, Rüdiger, Vodafone Group:

The question is: What happens on Firefox side. Of course it still tries to get 
to the OCSP server, but it should not cause an error on Firefox side if this 
does not work.


no, it does not because "security.OCSP.enabled = 0" and i saw at least
two requests to different servers failing with my Firefox with the
responder error from the webserver


What do you have security.OCSP.require set to? If it's "true" (a setting
no longer configurable through the UI, BTW, see
https://bugzilla.mozilla.org/show_bug.cgi?id=1034360), then Firefox
shows a fairly peculiar behavior: even when OCSP checking is disabled
(by setting security.OCSP.enabled to "0", through the "Query OCSP
responder servers to confirm the current validity of certificates"
preference in the UI under Advanced -> Certificates), it still includes
a status_request extension in the TLS handshake, and will subsequently
fail when it receives a stapled tryLater OCSP response, as long as
security.OCSP.require=true


security.OCSP.require=false is the default
but it's not only my client with random failed connections

[Sat Oct 03 00:15:01.478741 2015] [ssl:error] [pid 27458] 
(104)Connection reset by peer: [client 81.223.20.5:59844] AH01977: 
failed reading line from OCSP server
[Sat Oct 03 00:45:01.618792 2015] [ssl:error] [pid 4965] (104)Connection 
reset by peer: [client 81.223.20.5:33566] AH01977: failed reading line 
from OCSP server
[Sat Oct 03 01:15:01.589643 2015] [ssl:error] [pid 5599] (104)Connection 
reset by peer: [client 81.223.20.5:36218] AH01977: failed reading line 
from OCSP server
[Sat Oct 03 01:45:01.816132 2015] [ssl:error] [pid 4965] (104)Connection 
reset by peer: [client 81.223.20.5:38762] AH01977: failed reading line 
from OCSP server
[Sat Oct 03 02:15:01.187187 2015] [ssl:error] [pid 14361] 
(104)Connection reset by peer: [client 81.223.20.5:41043] AH01977: 
failed reading line from OCSP server
[Sat Oct 03 02:45:01.292205 2015] [ssl:error] [pid 14366] 
(104)Connection reset by peer: [client 81.223.20.5:42999] AH01977: 
failed reading line from OCSP server
[Sat Oct 03 03:15:01.353077 2015] [ssl:error] [pid 14364] 
(104)Connection reset by peer: [client 81.223.20.5:45180] AH01977: 
failed reading line from OCSP server
[Sat Oct 03 03:45:01.428090 2015] [ssl:error] [pid 14364] 
(104)Connection reset by peer: [client 81.223.20.5:46857] AH01977: 
failed reading line from OCSP server
[Sat Oct 03 04:15:02.019261 2015] [ssl:error] [pid 26399] 
(104)Connection reset by peer: [client 81.223.20.5:49007] AH01977: 
failed reading line from OCSP server




signature.asc
Description: OpenPGP digital signature

Re: [Patch] Async write completion for the full connection filter stack

[Graham Leggett]

On 28 Sep 2015, at 12:18 PM, Graham Leggett  wrote:

> Well, cracked the async problem for all file buckets and non-morphing 
> buckets, morphing buckets will currently still be flushed.
> 
> The solution to that seems to be to try keep a morphing bucket from reaching 
> the connection filters. A morphing bucket can safely be set aside in a 
> request filter without any problems with pools. If a filter existed at the 
> end of the request filters that detected morphing buckets and read them 
> before sending them downstream, that filter could safely set aside the rest 
> of the morphing bucket without being forced to read the whole thing in (and 
> thus block). If the filter received a flush the whole thing gets sent and we 
> block, but that’s what flush means so that’s fine.
> 
> Patch to follow.

Here is is.

Regards,
Graham
--


httpd-async-fullstack-ssl7.patch
Description: Binary data

Re: svn commit: r1706275 - /httpd/httpd/trunk/modules/ssl/ssl_engine_io.c

[Graham Leggett]

On 01 Oct 2015, at 8:22 PM, Ruediger Pluem  wrote:

> The issue is that openssl during the connect handshake to a clieent does not 
> tell httpd to flush. Hence the CLIENT_HELLO
> remains in the core output filter buffer and openssl waits for the 
> SERVER_HELLO from the remote server which of course
> does not happen without the CLIENT_HELLO having been sent there.
> 
> The whole game of reading and writing during the handshake happens inside 
> openssl while SSL_connect is running.
> Apache code only gets back into this via bio_filter_out_write and 
> bio_filter_in_read.

While working on the async write completion patch I was having all sorts of 
headaches with incomplete requests, and eventually reached the point where I 
removed THRESHOLD_MIN_WRITE completely and suddenly sanity returned across the 
board.

In the async code there is no way to assume you can not-write when you’ve been 
asked to write, because there is no way to tell whether more data is coming 
after this data. If you skip the write in the hope that more data comes but no 
data does come, you hang.

I get that THRESHOLD_MIN_WRITE was trying to prevent the sending of small 
packets, but really that should be solved by the filters themselves.

Regards,
Graham
—

Re: svn commit: r1703305 - /httpd/httpd/trunk/modules/aaa/mod_auth_digest.c

[Marion & Christophe JAILLET]

Le 01/10/2015 20:32, Ruediger Pluem a écrit :

On 09/16/2015 12:20 AM, jaillet...@apache.org wrote:

Author: jailletc36
Date: Tue Sep 15 22:20:45 2015
New Revision: 1703305

URL: http://svn.apache.org/r1703305
Log:
Remove code related to 'AuthDigestEnableQueryStringHack'

This has been undocumented for about 3 years now (see r1415960)

Modified:
 httpd/httpd/trunk/modules/aaa/mod_auth_digest.c

Could this cause

t/modules/digest.t

test 9 to fail?

As we removed the code for good reason we should also remove the test if this 
is the case then.

Regards

Rüdiger


Hi,
yes, you are right.

I would proposed the below patch:


Index: t/modules/digest.t
===
--- t/modules/digest.t(révision 1706466)
+++ t/modules/digest.t(copie de travail)
@@ -111,14 +111,20 @@
 # finally, the MSIE tests

 {
-  # fake current MSIE behavior - this should work as of 2.0.51
-  my $response = GET "$url?$query",
-   Authorization => $no_query_auth,
-   'X-Browser'   => 'MSIE';
-
-  ok t_cmp($response->code,
-   200,
-   'manual Authorization with no query string in header + MSIE');
+  if (have_min_apache_version("2.5.0")) {
+skip "'AuthDigestEnableQueryStringHack' has been removed in r1703305";
+  }
+  else
+  {
+# fake current MSIE behavior - this should work as of 2.0.51
+my $response = GET "$url?$query",
+ Authorization => $no_query_auth,
+ 'X-Browser'   => 'MSIE';
+
+ok t_cmp($response->code,
+ 200,
+ 'manual Authorization with no query string in header + MSIE');
+  }
 }

 {



This way, the test would still be done on 2.4.x where 
AuthDigestEnableQueryStringHack is still present, but not on trunk where 
I've removed it.


As I've never modified the test framework itself, please let me know if 
it is the correct way to do?


Best regards,
CJ

Re: Expression Parser: search and replace with s/PATTERN/REPLACEMENT/FLAGS

[Yann Ylavic]

On Thu, Oct 1, 2015 at 2:44 PM, Rainer Jung  wrote:
>
> OK, at least an encouragement for me to have a closer look.

+1!