Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72514
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.178 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CALwr1GnO+j2zDk+ykgF4E5O=quSOUPiZCcBbpmaqbH34j6xU0g@mail.gmail.com>
References: <CAH8Mpn=dhpKEM_fU=zq0JRx9G0mrD_E6duAu=Sz-6++Qt-TO_g@mail.gmail.com>
	<52FA932D.5050504@sugarcrm.com>
	<CAH8MpnnC6-gR5REPciKM4nXkXtquP3q5Z00d+WkA+Kz5vak4ZA@mail.gmail.com>
	<CALwr1GnO+j2zDk+ykgF4E5O=quSOUPiZCcBbpmaqbH34j6xU0g@mail.gmail.com>
Date: Wed, 12 Feb 2014 07:50:52 -0500
Message-ID: <CAH8MpnmorTAjYoPG_ApCYSV0QYJiDu79Hx7O9i76XYomO6_hGg@mail.gmail.com>
To: =?ISO-8859-1?Q?P=E1draic_Brady?= <padraic.brady@gmail.com>
Cc: Stas Malyshev <smalyshev@sugarcrm.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7b10caa5e0af9204f2350503
Subject: Re: [PHP-DEV] [VOTE] Improved TLS Defaults RFC
From: rdlowrey@gmail.com (Daniel Lowrey)

--047d7b10caa5e0af9204f2350503
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Feb 12, 2014 at 7:17 AM, P=E1draic Brady <padraic.brady@gmail.com>w=
rote:

> Hi,
>
> On 11 February 2014 21:53, Daniel Lowrey <rdlowrey@gmail.com> wrote:
> > On Tue, Feb 11, 2014 at 4:16 PM, Stas Malyshev <smalyshev@sugarcrm.com
> >wrote:
> >> - What is the motivation for verify_depth default of 3? RFC does not s=
ay
> >> anything on it.
> >>
> >>
> > I admit this one is a somewhat arbitrary limit (which explains the lack
> of
> > explanation in the wiki text). OpenSSL will default to a limit of 9 if =
we
> > don't specify one ourselves, so there's not really that much to be gain=
ed
> > by using a default of 3. After considering this a bit more I think it
> best
> > to eliminate the addition of a default value in this area altogether. I
> > will update the RFC and patch accordingly.
>
> It's partly arbitrary. The main reason for minimising depth, as far as
> I'm aware, is to minimise the cost of TLS. It's an expensive operation
> (even for the client) and having an infinite depth may, as far as I
> know, be a potential DOS risk. The general values used are 3-6
> reflecting real world use. A requirement for a value above this would
> indicate potential issues with the server. This may be something of a
> historical artifact since I cannot remember where I heard it. I do
> know that DOS against SSL servers used to justify limiting this value
> for certain.
>
> Paddy may need a memory upgrade...
>
> --
> P=E1draic Brady
>
> http://blog.astrumfutura.com
> http://www.survivethedeepend.com
> Zend Framework Community Review Team
> Zend Framework PHP-FIG Representative
>


This was my original line of thinking. However in my research I was unable
to find any real discussion centering around this issue as a significant
DoS vector. A couple of things to consider ...

1. Infinite descent is not an issue because, if unspecified, OpenSSL will
default to a verify depth of 9 as documented here:

https://www.openssl.org/docs/ssl/SSL_CTX_set_verify.html

2. If you're a client (far and away the more frequent use case in PHP) this
is really a non-issue. Servers aren't in the business of DoS'ing clients
and if they are doing something nefarious the solution is to simply not
connect to those servers.

3. I think it's generally safe to expect a bit more knowledge from
developers writing servers than those writing clients.

4. Servers verifying client certificates is only common in very specific
environments (e.g. corporate intranets). In these sorts of implementations
the verify depth will almost always be 0 for self-signed or 1 for an
internal/organizational CA. For these cases a feasible low default verify
depth setting is still not useful.

For these reasons I think it's best to leave out the additional default
setting for now. It would likely only result in failed transfers that would
otherwise have succeeded without adding very much real tangible security
benefit.

Daniel

--047d7b10caa5e0af9204f2350503--