Re: Confusion about SSLProxyCheckPeerName/CN

[William A Rowe Jr]

On Tue, May 31, 2016 at 11:37 AM, William A Rowe Jr 
wrote:

> It seems the behavior introduced in 2.4.5 is causing a lot
> of confusion for users attempting to disable peer checking.
>
> I would suggest that CheckPeerCN should NOT default to "on" any longer.
> The only valid use case is for the user to actively disable CheckPeerName
> (off), and has still wishes to actively enable CheckPeerCN (on).
>
> But we will need to improve this horrible CheckPeerName documentation for
> users of 2.4.5 through 2.4.20, even if we change the behavior
>

--- ssl_engine_io.c (revision 1746297)
+++ ssl_engine_io.c (working copy)
@@ -1200,7 +1200,7 @@
   "for hostname %s", hostname_note);
 }
 }
-else if ((sc->proxy_ssl_check_peer_cn != SSL_ENABLED_FALSE) &&
+else if ((sc->proxy_ssl_check_peer_cn == SSL_ENABLED_TRUE) &&
 hostname_note) {
 const char *hostname;
 int match = 0;


Seems to be the entire patch, no?

Bill

Re: Confusion about SSLProxyCheckPeerName/CN

[Ruediger Pluem]

On 05/31/2016 06:37 PM, William A Rowe Jr wrote:
> It seems the behavior introduced in 2.4.5 is causing a lot 
> of confusion for users attempting to disable peer checking.
> 
> Right now, nothing needs to be done to do deep inspection 
> (altsubjectname plus common name).  Neither directive is
> required, both default to on.
> 
> Disabling checking is a pain in the ass, and the docs seem
> to be very misleading;
> 
> 
> SSLProxyCheckPeerName Directive
> 
> Default:    
> |SSLProxyCheckPeerName on
> |
> 
> This directive configures host name checking for server certificates when 
> mod_ssl is acting as an SSL client. The check
> will succeed if the host name from the request URI is found in either the 
> subjectAltName extension or (one of) the CN
> attribute(s) in the certificate's subject. If the check fails, the SSL 
> request is aborted and a 502 status code (Bad
> Gateway) is returned. The directive supersedes |SSLProxyCheckPeerCN
> |, 
> which only checks for the expected host name
> in the first CN attribute.
> 
> 
> SSLProxyCheckPeerCN Directive
> 
> Default:    
> |SSLProxyCheckPeerCN on|
> 
> This directive sets whether the remote server certificate's CN field is 
> compared against the hostname of the request
> URL. If both are not equal a 502 status code (Bad Gateway) is sent.
> 
> In 2.4.5 and later, SSLProxyCheckPeerCN has been superseded by 
> |SSLProxyCheckPeerName
> |, 
> and its setting is only taken into account
> when |SSLProxyCheckPeerName off| is specified at the same time.
> 
> 
> So under CheckPeerName, we *claim* that the directive *supersedes* the 
> CheckPeerCN - but taking the only action you can
> with CheckPeerName (turning it off) falls right back into the trap of 
> CheckPeerCN, which *must* be *seperately*
> disabled. This behavior sucks.
> 
> I would suggest that CheckPeerCN should NOT default to "on" any longer. The 
> only valid use case is for the user to
> actively disable CheckPeerName (off), and has still wishes to actively enable 
> CheckPeerCN (on).
> 
> But we will need to improve this horrible CheckPeerName documentation for 
> users of 2.4.5 through 2.4.20, even if we
> change the behavior.
> 
> Thoughts?
> 
> 

As I felt into this trap a couple of days ago on my own a wholeheartedly +1.

Regards

Rüdiger

Confusion about SSLProxyCheckPeerName/CN

[William A Rowe Jr]

It seems the behavior introduced in 2.4.5 is causing a lot
of confusion for users attempting to disable peer checking.

Right now, nothing needs to be done to do deep inspection
(altsubjectname plus common name).  Neither directive is
required, both default to on.

Disabling checking is a pain in the ass, and the docs seem
to be very misleading;

SSLProxyCheckPeerName Directive
Default: 
SSLProxyCheckPeerName
on
This directive configures host name checking for server certificates when
mod_ssl is acting as an SSL client. The check will succeed if the host name
from the request URI is found in either the subjectAltName extension or
(one of) the CN attribute(s) in the certificate's subject. If the check
fails, the SSL request is aborted and a 502 status code (Bad Gateway) is
returned. The directive supersedes SSLProxyCheckPeerCN
,
which only checks for the expected host name in the first CN attribute.

SSLProxyCheckPeerCN Directive
Default: 
SSLProxyCheckPeerCN
on
This directive sets whether the remote server certificate's CN field is
compared against the hostname of the request URL. If both are not equal a
502 status code (Bad Gateway) is sent.

In 2.4.5 and later, SSLProxyCheckPeerCN has been superseded by
SSLProxyCheckPeerName
,
and its setting is only taken into account when SSLProxyCheckPeerName off is
specified at the same time.


So under CheckPeerName, we *claim* that the directive *supersedes* the
CheckPeerCN - but taking the only action you can with CheckPeerName
(turning it off) falls right back into the trap of CheckPeerCN, which
*must* be *seperately* disabled. This behavior sucks.

I would suggest that CheckPeerCN should NOT default to "on" any longer. The
only valid use case is for the user to actively disable CheckPeerName
(off), and has still wishes to actively enable CheckPeerCN (on).

But we will need to improve this horrible CheckPeerName documentation for
users of 2.4.5 through 2.4.20, even if we change the behavior.

Thoughts?

Re: New segfault with 2.4.20 with mod_perl

[William A Rowe Jr]

On Tue, May 31, 2016 at 7:35 AM, William A Rowe Jr 
wrote:

> On May 29, 2016 01:02, "Jie Gao"  wrote:
> >
> > Hi All
> >
> > I wonder if anybody is looking at this issue. At the moment, the build
> cores even at the end of generating a Makefile.
> >
> > If not, I would like to get my hands dirty in an attmpt to get the ball
> rolling. Any help on how to get a handle on the "ip comparisons"
> recommended by W. Rowe Jr would be much appreciated.
>
> Hi Jie,
>
> At the moment, I'm still on the fence of whether this is a supportable use
> case (in the faux-handler for the modperl alt protocol example.)
>
> If it is not, the fix is to drop the test from modperl.
>

Alternately, the test could be fixed, but that is non-trivial...

A non-request oriented alt protocol simply never examines the req_rec,
and must not use request oriented modules like auth.  That should be
pretty obvious.

To create a pseudo -request- handler, you would have your connection
hook handler populate the appropriate fields and insert the appropriate
protocol-specific input and output filters below the request/body filters
and run the request through the rest of the phases, performing the
auth validation at the appropriate phase of the request (post_read
would be one obvious choice.)

Otherwise, the fix is also straightforward, I can provide hints, but you
> can cause the fault by changing the domain name in the test case config
> from example 'hostname' to example 'ip addr'.  The offending code is in the
> backtrace.  Both ip and host lookups would test if the useragent_addr is
> null, and use the corresponding lookups from the conn_rec.
>
> I sort of expect the modperl test to continue to be broken because the
> req_rec simply has not been fully initialized... it is not until the entire
> read_req hook phase is complete that all these req_rec field members have
> meaningful values.
>
> But if enough folks agree we can fix the lookup to refer to the conn_rec
> values until useragent_addr is initialized.
>

Re: mod_fcgid: Immediate HTTP error 503 if the max total process count is reached

[Nick Kew]

On Tue, 2016-05-31 at 11:15 +0300, Ivan Zahariev wrote:
> Hello,
> 
> I got no feedback. Am I posting this suggestion at the right mailing
> list?

Sorry, I see your original post marked for attention in my mail
folder, but languishing hitherto unattended.  Just now opened your
link in a browser to take a look.  There could be others who
have done something similar.

As a general reply to this question, yes, this is the best
available mailinglist.  The other place to post it would be
as an enhancement request in bugzilla (issues.apache.org).
The keyword "PatchAvailable" there may help by marking it as
low-hanging fruit.

-- 
Nick Kew

Re: mod_fcgid: Immediate HTTP error 503 if the max total process count is reached

[Ivan Zahariev]

Hello,

I got no feedback. Am I posting this suggestion at the right mailing list?

Best regards.
--Ivan

On 19.5.2016 г. 10:40 ч., Ivan Zahariev wrote:

Hi all,

I'd like to propose a new configuration setting for "mod_fcgid". The 
source code changes to review follow:


  * The whole patch compared to version 2.3.9:

https://github.com/famzah/mod_fcgid/compare/2.3.9...maxnowait?diff=split=maxnowait
  * The whole patch as a single file:

https://github.com/famzah/mod_fcgid/compare/2.3.9...maxnowait.patch?diff=unified=maxnowait
  * Every single commit compared to version 2.3.9:
https://github.com/famzah/mod_fcgid/commits/maxnowait
  * There should be no merge conflicts with the current "trunk"
version 2.3.10.


The motivation is that the current behavior to queue up new pending 
requests differs from the RLimitNPROC directive behavior. When there 
is a spike in the web hits, lots of Apache children get busy just 
waiting for up to 30+ seconds to get an idle FastCGI process. Thus we 
"waste" Apache children doing nothing while they could serve static 
content. This also puts unneeded memory pressure. Additionally, users 
today won't wait for a page to load, if it takes more than a few 
seconds, and we'd rather notify them that we are currently overloaded 
by sending them a 503 HTTP response immediately.


Here is the documentation for the new directive: 
http://www.famzah.net/temp/FcgidMaxProcessesUsedNoWait.docs.txt


Let me know what you think.

Best regards.
--Ivan