Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71957
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAH8Mpn=a-2As60NPd22TEAP5hyfbaU=KJHxL-=ZM__b=Yp8OSA@mail.gmail.com>
References: <CAH8MpnmVnYiw7nJ11v+h=31+p+HBopBjJ80afpZkW-bW1LJb2A@mail.gmail.com>
	<CALwr1GnCqXZUk5zDfmtBa8cqmZS9qiGxVtc0JAbpShsJPodhtw@mail.gmail.com>
	<CAH8Mpn=1OMhKjMPAFGQ6hF309zFN4=ZFMZc06ZQvT8S2vX4hJw@mail.gmail.com>
	<824758DB-57D8-4B4B-BECD-E1F12531FDE0@rouvenwessling.de>
	<CAH8Mpn=3D7bSWQicgaRPKBtriqkk08p8Jh0+ud6N8BEbJXAu7w@mail.gmail.com>
	<CAGa2bXaKiKzQvEpb-8Y0YtXip4TGwNXsErkwEgOrocyP7WHa8w@mail.gmail.com>
	<CAH8MpnnRYCd3dX=7Y7C63TqNGCh2gRVsodctiRrjJkvNS7Zb1g@mail.gmail.com>
	<CAH8Mpn=a-2As60NPd22TEAP5hyfbaU=KJHxL-=ZM__b=Yp8OSA@mail.gmail.com>
Date: Sun, 2 Feb 2014 00:27:55 +0000
Message-ID: <CALwr1GnHtUu7jU2K7LP8XcJXDPAaKK3uNvnsY587Bv1F-kGw+Q@mail.gmail.com>
To: Daniel Lowrey <rdlowrey@gmail.com>
Cc: Yasuo Ohgaki <yohgaki@ohgaki.net>, =?UTF-8?Q?Rouven_We=C3=9Fling?= <me@rouvenwessling.de>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0122a26e7ed26104f1617a52
Subject: Re: [PHP-DEV] Improved TLS Defaults
From: padraic.brady@gmail.com (=?UTF-8?Q?P=C3=A1draic_Brady?=)

--089e0122a26e7ed26104f1617a52
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Daniel,

Looking at the openssl output, this eliminates all weak ciphersuites. I'm
testing using the Qualys service at:
https://www.ssllabs.com/ssltest/viewMyClient.html

I have two things to be considered on top of this:

1. If you check the ciphersuite order of the proposed ciphers vs cURL
(current HEAD) vs Mozilla (https://wiki.mozilla.org/Security/Server_Side_TL=
S),
the ciphers which support perfect forward secrecy are dispersed throughout
the list for the RFC and cURL so numerous non-PRS ciphers will gain
preference over PFS ciphers. PFS has become a big deal recently with people
worried about companies having their private keys stolen or handed over on
foot of a warrant by a three letter agency. I think we should take this
opportunity to follow the trend and that's basically why Mozilla have such
a long explicit ordering in their suite.
2. There has been some questions raised about the efficacy of stronger 256
ciphers vs 128 ciphers. The Mozilla list therefore reorders the ciphers to
prefer the faster 128 ciphers while still maintaining the preference for
PFS first. The base reference for this is:
https://www.schneier.com/blog/archives/2009/07/new_attack_on_a.html. This
describes an attack valid for AES256 but NOT for AES128. To be fair, the
attack should be beyond anyone's computational resources at this time but
as the old pessimist's view goes, if it breaks once, it'll probably break
again, and again, ad infinitum. So if we were to be extremely cautious,
preferring AES128 would be the ticket.

Looking around, it's clear that choosing a cipher suite is not an easy
task. Mozilla, IE and Chromium all differ. cURL and openssl also differ
from the browsers. cURL recently amended its list away from the openssl
DEFAULT on foot of a security report but I don't think they put sufficient
thought into it and basically relied on openssl's judgement for the most
part. In the absence of openssl amending DEFAULT (which may well happen at
some point - it was reported to them afterall), I think Mozilla has the
better approach.

The other outcome of the Mozilla ciphersuite is that it removes all ciphers
below 128 (there's about 15 or so below that waterline). These are not
reported as weak on the Qualys site or howsmyssl.com, however, so not sure
if it's necessary in our case at this time.

Paddy

--
P=C3=A1draic Brady

http://blog.astrumfutura.com
http://phpsecurity.readthedocs.org
Zend Framework Community Review Team
Zend Framework PHP-FIG Representative

--089e0122a26e7ed26104f1617a52--