Re: Confusion about SSLProxyCheckPeerName/CN

2016-06-01 Thread Ruediger Pluem 


On 06/01/2016 05:45 PM, William A Rowe Jr wrote:
> 
> 
> On Wed, Jun 1, 2016 at 9:46 AM, Ruediger Pluem  > wrote:
> 
> 
> 
> On 06/01/2016 04:19 PM, William A Rowe Jr wrote:
> > Correcting one typo, below...
> >
> > On Wed, Jun 1, 2016 at 9:19 AM, William A Rowe Jr    >> wrote:
> >
> >
> > Proposal...
> >
> > CheckPeerName  CheckPeerCN
> >  unset | onunset | onCheckPeerName verification
> >  off   on*CheckPeerCN* verification
> >  off   unset | off   no verification
> >  unset | off   off   no verification
> >
> > WDYT?
> >
> >
> >
> 
> In general yes plus
> 
> CheckPeerName  CheckPeerCN
>   onunset | offCheckPeerName verification
> 
> 
> What about one more exceptional case... where the
> 
> CheckPeerCN On
> 
> is the only directive?  Do we still want to enable CheckPeerName by default?
> 
>   CheckPeerName  CheckPeerCN
>on {ignored}CheckPeerName verification
>unset unset CheckPeerName verification
>unset onCheckPeerName or CheckPeerCN verification?

I think CheckPeerName is ok in this case.

>unset off   no verification
>off   on*CheckPeerCN* verification
>off   unset | off   no verification
>
> Because CheckPeerName is a superset of the CheckPeerCN functionality,
> I don't think there is any harm is using CheckPeerName in this case.
> 
>  

Regards

Rüdiger

[RESULTS] [POLL] Commitment to 2.2.x lifecycle? (Was: End of the road of 2.2.x maintenance?)

2016-06-01 Thread William A Rowe Jr 
On Wed, May 25, 2016 at 10:11 AM, William A Rowe Jr 
wrote:

>
> So let's try this... would 2.2.x maintainers and PMC folks please answer
> this
> poll -if- you have an intention to help throughout the wind-down of 2.2.x,
> since
> this is all predicated on having committed-committers to participate.
> This isn't
> to say folks refuse to participate after the time period you offer, but
> for how long
> you are personally prepared to participate.  [If you aren't a 2.2.x legacy
> branch
> participant, testing RCs or applying backports, then no response is
> needed.]
>
>  *) I intend to help maintain/test 2.2.x releases over the next [] mos
>

Thanks for all your feedback... if my tally is correct;

6 mos 12 mos 18 mos
covener covener covener
wrowe
rpluem
druggeri
rjung
jorton wrowe
rpluem
druggeri
rjung
jorton
gsmith


>
>  *) I intend to backport/review 2.2.x security patches over the next
> [] mos
>


6 mos 12 mos 18 mos
drugerri
covener
rjung
yann drugerri
covener
rjung
yann drugerri
covener
rjung
yann
wrowe
rpluem
jaillet
jorton wrowe
rpluem
jailletc36
jorton
gls

It seems we can safely call out the following in the 2.4.21 and future 2.2.x
releases;

"The Apache Web Server Project will continue to provide maintenance
releases of the 2.2.x flavor through June of 2017, and will provide some
security patches beyond this date through at least December of 2017.
Minimal maintenance patches are expected throughout this period,
and users are strongly encouraged to complete their transitions to
the 2.4.x flavor of httpd on an expedited basis to benefit from a larger
assortment of bug fixes, software robustness and new features."

Or something along those lines.

Re: Confusion about SSLProxyCheckPeerName/CN

2016-06-01 Thread William A Rowe Jr 
On Wed, Jun 1, 2016 at 9:46 AM, Ruediger Pluem  wrote:

>
>
> On 06/01/2016 04:19 PM, William A Rowe Jr wrote:
> > Correcting one typo, below...
> >
> > On Wed, Jun 1, 2016 at 9:19 AM, William A Rowe Jr  > wrote:
> >
> >
> > Proposal...
> >
> > CheckPeerName  CheckPeerCN
> >  unset | onunset | onCheckPeerName verification
> >  off   on*CheckPeerCN* verification
> >  off   unset | off   no verification
> >  unset | off   off   no verification
> >
> > WDYT?
> >
> >
> >
>
> In general yes plus
>
> CheckPeerName  CheckPeerCN
>   onunset | offCheckPeerName verification
>

What about one more exceptional case... where the

CheckPeerCN On

is the only directive?  Do we still want to enable CheckPeerName by default?

  CheckPeerName  CheckPeerCN
   on {ignored}CheckPeerName verification
   unset unset CheckPeerName verification
   unset onCheckPeerName or CheckPeerCN verification?
   unset off   no verification
   off   on*CheckPeerCN* verification
   off   unset | off   no verification

Because CheckPeerName is a superset of the CheckPeerCN functionality,
I don't think there is any harm is using CheckPeerName in this case.

Re: Confusion about SSLProxyCheckPeerName/CN

2016-06-01 Thread Ruediger Pluem 


On 06/01/2016 04:19 PM, William A Rowe Jr wrote:
> Correcting one typo, below...
> 
> On Wed, Jun 1, 2016 at 9:19 AM, William A Rowe Jr  > wrote:
> 
> 
> Proposal...
> 
> CheckPeerName  CheckPeerCN
>  unset | onunset | onCheckPeerName verification
>  off   on*CheckPeerCN* verification
>  off   unset | off   no verification
>  unset | off   off   no verification
> 
> WDYT?
> 
> 
> 

In general yes plus

CheckPeerName  CheckPeerCN
  onunset | offCheckPeerName verification


Regards

Rüdiger

Re: Confusion about SSLProxyCheckPeerName/CN

2016-06-01 Thread William A Rowe Jr 
Correcting one typo, below...

On Wed, Jun 1, 2016 at 9:19 AM, William A Rowe Jr 
wrote:

>
> Proposal...
>
> CheckPeerName  CheckPeerCN
>  unset | onunset | onCheckPeerName verification
>  off   on*CheckPeerCN* verification
>  off   unset | off   no verification
>  unset | off   off   no verification
>
> WDYT?
>
>
>

Re: Confusion about SSLProxyCheckPeerName/CN

2016-06-01 Thread William A Rowe Jr 
On Tue, May 31, 2016 at 1:15 PM, Ruediger Pluem  wrote:

>
> 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: <
> http://httpd.apache.org/docs/2.4/mod/directive-dict.html#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: <
> http://httpd.apache.org/docs/2.4/mod/directive-dict.html#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


Thinking about this further, I don't know that this fix is correct.

A user on 2.4.3 (there are many) will be broken moving to 2.4.21 if their
config
simply reads;

SSLProxyCheckPeerCN off

Their intent was pretty clear, turn off this test. The fact that we added
the
alt subject names and wildcard domains doesn't address the fact that the
user simply wanted this turned *off* and the user is *not* supposed to ever
need to change their configuration from one subversion release to another.
We are *not* supposed to change the behavior of the server in unexpected
ways from one subversion release to another.

Proposal...

CheckPeerName  CheckPeerCN
 unset | onunset | onCheckPeerName verification
 off   onCheckPeerName verification
 off   unset | off   no verification
 unset | off   off   no verification

WDYT?

Re: [POLL] Commitment to 2.2.x lifecycle? (Was: End of the road of 2.2.x maintenance?)

2016-06-01 Thread Joe Orton 
On Wed, May 25, 2016 at 10:11:40AM -0500, William A Rowe Jr wrote:
> you are personally prepared to participate.  [If you aren't a 2.2.x 
> legacy branch participant, testing RCs or applying backports, then no 
> response is needed.]
> 
>  *) I intend to help maintain/test 2.2.x releases over the next [12] mos
> 
>  *) I intend to backport/review 2.2.x security patches over the next [12]
> mos

I can certainly test a "final"-ish 2.2 release in this timescale though 
I may need a prod :)

For selected (Critical) security issues we'll still be working on 2.2 
backports through to 2020 for RHEL6, so likely I or somebody else @ Red 
Hat will be willing to co-operate upstream on backports, if only in 
patches/ or whatever.

Regards, Joe