Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72480
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.181 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <52FA932D.5050504@sugarcrm.com>
References: <CAH8Mpn=dhpKEM_fU=zq0JRx9G0mrD_E6duAu=Sz-6++Qt-TO_g@mail.gmail.com>
	<52FA932D.5050504@sugarcrm.com>
Date: Tue, 11 Feb 2014 16:53:03 -0500
Message-ID: <CAH8MpnnC6-gR5REPciKM4nXkXtquP3q5Z00d+WkA+Kz5vak4ZA@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1134db8604818304f2287bdf
Subject: Re: [PHP-DEV] [VOTE] Improved TLS Defaults RFC
From: rdlowrey@gmail.com (Daniel Lowrey)

--001a1134db8604818304f2287bdf
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Feb 11, 2014 at 4:16 PM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

>
> Wouldn't it also be good to have a constant that has the
> meaning of "every protocol you can possibly support (including TLS
> protocols)"?
>
>
This is a good point. For this reason it probably makes to either:

1. NOT re-purpose the two STREAM_CRYPTO_METHOD_SSLv23_* constants to mean
SSLv2 or SSLv3 (retain the OpenSSL semantics of SSLv23)
2. Introduce two new constants, STREAM_CRYPTO_CLIENT and
STREAM_CRYPTO_SERVER to mean "anything we can possibly support"

I have a mild preference for #2 as it eliminates confusion that can arise
if you don't have a firm grasp of what OpenSSL means by SSLv23 but am
certainly willing to listen to the preponderance of opinion from others
here.


> - What is the motivation for verify_depth default of 3? RFC does not say
> 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 gained
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.


> - What is the use case for honor_cipher_order? If the client is "bad",
> they won't use honor_cipher_order and thus this option doesn't add to
> security. If the client is "well-behaved", they would use the correct
> set of cyphers. Is this setting meant for PHP servers? Because the
> example clearly uses client side.
>

Woops! This is a copy/paste error in my example. The honor_cipher_order
only ever has meaning for servers. I will update the example on the wiki to
reflect to correct (server) usage shortly.

--001a1134db8604818304f2287bdf--