httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruediger Pluem <rpl...@apache.org>
Subject Re: Confusion about SSLProxyCheckPeerName/CN
Date Tue, 31 May 2016 18:15:52 GMT


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



Mime
View raw message