On Tue, May 31, 2016 at 1:15 PM, Ruediger Pluem <rpl...@apache.org> 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 > > <http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#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 > > <http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#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 | on unset | on CheckPeerName verification off on CheckPeerName verification off unset | off no verification unset | off off no verification WDYT?
