Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 545F92009E2 for ; Wed, 1 Jun 2016 16:19:20 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 5298A160A4C; Wed, 1 Jun 2016 14:19:20 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 4B8E3160A45 for ; Wed, 1 Jun 2016 16:19:19 +0200 (CEST) Received: (qmail 63973 invoked by uid 500); 1 Jun 2016 14:19:18 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 63960 invoked by uid 99); 1 Jun 2016 14:19:18 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Jun 2016 14:19:18 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 0D82F1800A4 for ; Wed, 1 Jun 2016 14:19:18 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.298 X-Spam-Level: * X-Spam-Status: No, score=1.298 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=rowe-clan-net.20150623.gappssmtp.com Received: from mx2-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id F7joJVXNd0zt for ; Wed, 1 Jun 2016 14:19:16 +0000 (UTC) Received: from mail-io0-f173.google.com (mail-io0-f173.google.com [209.85.223.173]) by mx2-lw-eu.apache.org (ASF Mail Server at mx2-lw-eu.apache.org) with ESMTPS id 66B785F368 for ; Wed, 1 Jun 2016 14:19:15 +0000 (UTC) Received: by mail-io0-f173.google.com with SMTP id p194so22264926iod.1 for ; Wed, 01 Jun 2016 07:19:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rowe-clan-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=t3zFC81EGOGIaoxb3WsBJZ4Y/iv80snZvIKtJmpNgrM=; b=ksfOnnP3ycGAdiARwO9LA5RNYpUueI/m5RIiuolb0Zs+7zR5GQ5OPQ2oD6tr/eJ8Fp yi/aNRpFcx+AACw7R4CfYphqI/CU7A2MJXh5Xfjp4UzklghWAHRXsSqfMSAHVf2/RU+v BBintEKD1FWfFJ+sWSWLBGcsKE8ho2MrZipODq4muUq7yeZ4uvQuir4Rf0PdoSqu3hcM NNH2e1KKMrRZaEB7w59i0iLIWBoIxd2c2s8qVBxs/G9p9zxDX//48GxPOsZPaxsMl/22 IwdRm6aUvfzFbFbo28fZCYHpjykrgBsjXLiR85k28KRqbG9huGAJHGdWbcYOVd61H+QD v8Iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=t3zFC81EGOGIaoxb3WsBJZ4Y/iv80snZvIKtJmpNgrM=; b=j+bMnEvhJhIZ6tMuGAvslPKM46Z5+oUo13jMwNrz0mj6JEC1qQtduphcxSM/FJbA30 cavKRZlAK1GSwJC/Ba3HG8m9YFgoroS6F6g78KMHyB9yNMRWZpO+SE4FhiISR24cwbY/ wau3lopdN8gtirZTmzC+TzTkMMv5OfzHxpXTjPEUiyPgO1vMgGfGDUmGUrZNL+tzXLrD ufY7i8Xj9E65TGVrWQwlsJ0cImdHouc6/sw4rBRyzOAH4jX/HqGiNzKdB895BpZ0ojj+ bI2lFPaiycSENeliKxIJQunooe/h0MlKo6FNAMKonahGTrBgLo0146oy46Dxx/Kzo4li N6eQ== X-Gm-Message-State: ALyK8tIXHrSTjAi74OTnCk86xfTvOU5LRDGztMNuwsGk5m1pgH92zUxOdD+DiPRi7eV0sO41f31M39B/da5RF2Vp MIME-Version: 1.0 X-Received: by 10.107.27.18 with SMTP id b18mr5768191iob.163.1464790754261; Wed, 01 Jun 2016 07:19:14 -0700 (PDT) Received: by 10.107.50.199 with HTTP; Wed, 1 Jun 2016 07:19:14 -0700 (PDT) In-Reply-To: <574DD4D8.10902@apache.org> References: <574DD4D8.10902@apache.org> Date: Wed, 1 Jun 2016 09:19:14 -0500 Message-ID: Subject: Re: Confusion about SSLProxyCheckPeerName/CN From: William A Rowe Jr To: httpd Cc: docs@httpd.apache.org Content-Type: multipart/alternative; boundary=001a1140a2a0944d010534382c1e archived-at: Wed, 01 Jun 2016 14:19:20 -0000 --001a1140a2a0944d010534382c1e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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=C3=BCdiger 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? --001a1140a2a0944d010534382c1e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, May 31, 2016 at 1:15 PM, Ruediger Pluem <rpluem@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).=C2=A0 Neither directive is
> required, both default to on.
>
> Disabling checking is a pain in the ass, and the docs seem
> to be very misleading;
>
>
>=C2=A0 =C2=A0 =C2=A0SSLProxyCheckPeerName Directive
>
> Default: <http://http= d.apache.org/docs/2.4/mod/directive-dict.html#Default>=C2=A0 =C2=A0|= SSLProxyCheckPeerName on
> |
>
> This directive configures host name checking for server certificates w= hen 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.ap= ache.org/docs/2.4/mod/mod_ssl.html#sslproxycheckpeercn>|, which only= checks for the expected host name
> in the first CN attribute.
>
>
>=C2=A0 =C2=A0 =C2=A0SSLProxyCheckPeerCN Directive
>
> Default: <http://http= d.apache.org/docs/2.4/mod/directive-dict.html#Default>=C2=A0 =C2=A0|= SSLProxyCheckPeerCN on|
>
> This directive sets whether the remote server certificate's CN fie= ld 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 |SSLPro= xyCheckPeerName
> <http://httpd.= apache.org/docs/2.4/mod/mod_ssl.html#sslproxycheckpeername>|, and it= s 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 wholeheart= edly +1.

Regards

R=C3=BCdiger

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

A user o= n 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 do= esn't address the fact that the
user simply wanted this turne= d *off* and the user is *not* supposed to ever
need to change the= ir 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.

Propo= sal...

CheckPe= erName =C2=A0CheckPeerCN
=C2=A0unset | on =C2=A0 =C2=A0unset | on =C2=A0 =C2=A0CheckPeerName = verification
=C2= =A0 =C2=A0 =C2=A0off =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 on =C2=A0 =C2=A0 = =C2=A0 =C2=A0CheckPeerName verification
=C2=A0 =C2=A0 =C2=A0off =C2=A0 =C2=A0 =C2=A0 u= nset | off =C2=A0 no verification
=C2=A0unset | off =C2=A0 =C2=A0 =C2=A0 off =C2=A0 = =C2=A0 =C2=A0 no verification

WDYT?


--001a1140a2a0944d010534382c1e--