You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by William A Rowe Jr <wr...@rowe-clan.net> on 2016/06/01 14:19:14 UTC
Re: Confusion about SSLProxyCheckPeerName/CN
On Tue, May 31, 2016 at 1:15 PM, Ruediger Pluem <rp...@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?
Re: Confusion about SSLProxyCheckPeerName/CN
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Jun 2, 2016 7:06 PM, "Daniel Ruggeri" <DR...@primary.net> wrote:
>
> On 6/1/2016 9:19 AM, William A Rowe Jr wrote:
> >
> > Proposal...
> >
> > CheckPeerName CheckPeerCN
> > unset | on unset | on CheckPeerName verification
> > off on *CheckPeerCN* verification
> > off unset | off no verification
> > unset | off off no verification
> >
> > WDYT?
>
> +1
>
> ... but it is probably a very unlikely scenario for an administrator to
> want to disable checking of SAN entries but to enable checking of CN
> (the off/on scenario above). I'd argue it's reasonable to make both
> directives simple toggles CheckPeerName verification, but I still agree
> that we cannot make an existing config represent X in version 1.2.3 and
> represent Y in version 1.2.4 so CheckPeerCN logic should be retained.
You have me a little confused.
The existing (2.4.20) behavior is a superset of the legacy (2.4.4)
behavior. Nobody has become confused since 2.4.5 that the program is
suddenly accepting wildcard matches or altSubjectName matches.
They are confused because previously disabling CheckCN no longer disables
the check.
There remains one and only config in the proposed fix which correctly
processes CheckCN, and it happens to mirror a previously explicit and
correct config.
Anyone upgrading since 2.4.4 with no directives at all will gain the
benefit of wildcard and altSubjectName matches, which I don't see as
detrimental. I think the patch as proposed is the best compromise, and
hope the docs explanation is as clear as can be.
Re: Confusion about SSLProxyCheckPeerName/CN
Posted by Daniel Ruggeri <DR...@primary.net>.
On 6/1/2016 9:19 AM, William A Rowe Jr wrote:
>
> Proposal...
>
> CheckPeerName CheckPeerCN
> unset | on unset | on CheckPeerName verification
> off on *CheckPeerCN* verification
> off unset | off no verification
> unset | off off no verification
>
> WDYT?
+1
... but it is probably a very unlikely scenario for an administrator to
want to disable checking of SAN entries but to enable checking of CN
(the off/on scenario above). I'd argue it's reasonable to make both
directives simple toggles CheckPeerName verification, but I still agree
that we cannot make an existing config represent X in version 1.2.3 and
represent Y in version 1.2.4 so CheckPeerCN logic should be retained.
--
Daniel Ruggeri
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: Confusion about SSLProxyCheckPeerName/CN
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
This looks like the resulting patch. Wordsmithing the docs changes today...
On Wed, Jun 1, 2016 at 1:50 PM, Ruediger Pluem <rp...@apache.org> wrote:
>
> On 06/01/2016 05:45 PM, William A Rowe Jr wrote:
> >
> > CheckPeerName CheckPeerCN
> > on {ignored} CheckPeerName verification
> > unset unset CheckPeerName verification
> > unset on CheckPeerName 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.
> >
>
> I think CheckPeerName is ok in this case.
>
> Regards
>
> Rüdiger
>
Index: ssl_engine_io.c
===================================================================
--- ssl_engine_io.c (revision 1746587)
+++ ssl_engine_io.c (working copy)
@@ -1189,6 +1189,8 @@
}
}
if ((sc->proxy_ssl_check_peer_name != SSL_ENABLED_FALSE) &&
+ ((sc->proxy_ssl_check_peer_cn != SSL_ENABLED_FALSE) ||
+ (sc->proxy_ssl_check_peer_name == SSL_ENABLED_TRUE)) &&
hostname_note) {
apr_table_unset(c->notes, "proxy-request-hostname");
if (!cert
@@ -1200,7 +1202,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;
Re: Confusion about SSLProxyCheckPeerName/CN
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
This looks like the resulting patch. Wordsmithing the docs changes today...
On Wed, Jun 1, 2016 at 1:50 PM, Ruediger Pluem <rp...@apache.org> wrote:
>
> On 06/01/2016 05:45 PM, William A Rowe Jr wrote:
> >
> > CheckPeerName CheckPeerCN
> > on {ignored} CheckPeerName verification
> > unset unset CheckPeerName verification
> > unset on CheckPeerName 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.
> >
>
> I think CheckPeerName is ok in this case.
>
> Regards
>
> Rüdiger
>
Index: ssl_engine_io.c
===================================================================
--- ssl_engine_io.c (revision 1746587)
+++ ssl_engine_io.c (working copy)
@@ -1189,6 +1189,8 @@
}
}
if ((sc->proxy_ssl_check_peer_name != SSL_ENABLED_FALSE) &&
+ ((sc->proxy_ssl_check_peer_cn != SSL_ENABLED_FALSE) ||
+ (sc->proxy_ssl_check_peer_name == SSL_ENABLED_TRUE)) &&
hostname_note) {
apr_table_unset(c->notes, "proxy-request-hostname");
if (!cert
@@ -1200,7 +1202,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;
Re: Confusion about SSLProxyCheckPeerName/CN
Posted by Ruediger Pluem <rp...@apache.org>.
On 06/01/2016 05:45 PM, William A Rowe Jr wrote:
>
>
> On Wed, Jun 1, 2016 at 9:46 AM, Ruediger Pluem <rpluem@apache.org <ma...@apache.org>> 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 <wrowe@rowe-clan.net <ma...@rowe-clan.net> <mailto:wrowe@rowe-clan.net <ma...@rowe-clan.net>>> wrote:
> >
> >
> > Proposal...
> >
> > CheckPeerName CheckPeerCN
> > unset | on unset | on CheckPeerName verification
> > off on *CheckPeerCN* verification
> > off unset | off no verification
> > unset | off off no verification
> >
> > WDYT?
> >
> >
> >
>
> In general yes plus
>
> CheckPeerName CheckPeerCN
> on unset | off CheckPeerName 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 on CheckPeerName 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
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: Confusion about SSLProxyCheckPeerName/CN
Posted by Ruediger Pluem <rp...@apache.org>.
On 06/01/2016 05:45 PM, William A Rowe Jr wrote:
>
>
> On Wed, Jun 1, 2016 at 9:46 AM, Ruediger Pluem <rpluem@apache.org <ma...@apache.org>> 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 <wrowe@rowe-clan.net <ma...@rowe-clan.net> <mailto:wrowe@rowe-clan.net <ma...@rowe-clan.net>>> wrote:
> >
> >
> > Proposal...
> >
> > CheckPeerName CheckPeerCN
> > unset | on unset | on CheckPeerName verification
> > off on *CheckPeerCN* verification
> > off unset | off no verification
> > unset | off off no verification
> >
> > WDYT?
> >
> >
> >
>
> In general yes plus
>
> CheckPeerName CheckPeerCN
> on unset | off CheckPeerName 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 on CheckPeerName 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
Re: Confusion about SSLProxyCheckPeerName/CN
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Wed, Jun 1, 2016 at 9:46 AM, Ruediger Pluem <rp...@apache.org> 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 <wrowe@rowe-clan.net
> <ma...@rowe-clan.net>> wrote:
> >
> >
> > Proposal...
> >
> > CheckPeerName CheckPeerCN
> > unset | on unset | on CheckPeerName verification
> > off on *CheckPeerCN* verification
> > off unset | off no verification
> > unset | off off no verification
> >
> > WDYT?
> >
> >
> >
>
> In general yes plus
>
> CheckPeerName CheckPeerCN
> on unset | off CheckPeerName 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 on CheckPeerName 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
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Wed, Jun 1, 2016 at 9:46 AM, Ruediger Pluem <rp...@apache.org> 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 <wrowe@rowe-clan.net
> <ma...@rowe-clan.net>> wrote:
> >
> >
> > Proposal...
> >
> > CheckPeerName CheckPeerCN
> > unset | on unset | on CheckPeerName verification
> > off on *CheckPeerCN* verification
> > off unset | off no verification
> > unset | off off no verification
> >
> > WDYT?
> >
> >
> >
>
> In general yes plus
>
> CheckPeerName CheckPeerCN
> on unset | off CheckPeerName 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 on CheckPeerName 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
Posted by Ruediger Pluem <rp...@apache.org>.
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 <wrowe@rowe-clan.net <ma...@rowe-clan.net>> wrote:
>
>
> Proposal...
>
> CheckPeerName CheckPeerCN
> unset | on unset | on CheckPeerName verification
> off on *CheckPeerCN* verification
> off unset | off no verification
> unset | off off no verification
>
> WDYT?
>
>
>
In general yes plus
CheckPeerName CheckPeerCN
on unset | off CheckPeerName verification
Regards
R�diger
Re: Confusion about SSLProxyCheckPeerName/CN
Posted by Ruediger Pluem <rp...@apache.org>.
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 <wrowe@rowe-clan.net <ma...@rowe-clan.net>> wrote:
>
>
> Proposal...
>
> CheckPeerName CheckPeerCN
> unset | on unset | on CheckPeerName verification
> off on *CheckPeerCN* verification
> off unset | off no verification
> unset | off off no verification
>
> WDYT?
>
>
>
In general yes plus
CheckPeerName CheckPeerCN
on unset | off CheckPeerName verification
Regards
R�diger
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org
Re: Confusion about SSLProxyCheckPeerName/CN
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
Correcting one typo, below...
On Wed, Jun 1, 2016 at 9:19 AM, William A Rowe Jr <wr...@rowe-clan.net>
wrote:
>
> Proposal...
>
> CheckPeerName CheckPeerCN
> unset | on unset | on CheckPeerName verification
> off on *CheckPeerCN* verification
> off unset | off no verification
> unset | off off no verification
>
> WDYT?
>
>
>