Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:101237
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <10a39b35-57e2-d6c4-ea3a-75b47d8df514@rhsoft.net>
References: <a64088a5-e93b-3450-fe8c-8ba6ac9d851a@php.net> <CADNQb0VA+-E2B21EZCfzau7v0_0=SeheHB+cxZCsx7RoVNn8jA@mail.gmail.com>
 <41630a4e-8772-bdfb-e859-831a36dc67ea@rhsoft.net> <CANUQDCjsz31t-VqbLeUOc-qJd=wzQ8Tbk2UGhY-74xw+JaGHUA@mail.gmail.com>
 <e8b900c3-3d76-9fe0-7b96-3c1f468d160e@rhsoft.net> <CAESVnVqhNgge2dzHTbf1bCR0unGCYwEeDqS2ErWdyK34M26k6g@mail.gmail.com>
 <9f3d28e1-cc6d-d5dc-da04-7e3791070be8@rhsoft.net> <CAESVnVoWeNdh2R4KROe=CfACQVQJP9sf66iJASPp73nURi9ouw@mail.gmail.com>
 <35e8f8c5-8fe0-702b-f304-890cf902b390@rhsoft.net> <b9075c8d-a5e1-8b28-cde7-8a642abaf0d0@rhsoft.net>
 <CANUQDCgEqxAT4+kiTFsg7yxoktZ+upWV6OD7wW9ggME2OMcAfg@mail.gmail.com>
 <CAMPTd_A2DB4_mysLeaTkcNFTZtrseNqWsmtaxjG6E_vPo7ghkg@mail.gmail.com> <10a39b35-57e2-d6c4-ea3a-75b47d8df514@rhsoft.net>
Date: Mon, 4 Dec 2017 16:19:56 -0800
Message-ID: <CAMPTd_CrBtfh0BwP=_aqjyRV2qwTooDGAd+tU4+5m4cG=bsY4A@mail.gmail.com>
To: "lists@rhsoft.net" <lists@rhsoft.net>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="001a11c1342878ad35055f8ccb48"
Subject: Re: [PHP-DEV] PHP 7.2.0 Released
From: walterp@gmail.com (Walter Parker)

--001a11c1342878ad35055f8ccb48
Content-Type: text/plain; charset="UTF-8"

On Mon, Dec 4, 2017 at 2:21 PM, lists@rhsoft.net <lists@rhsoft.net> wrote:

>
>
> Am 04.12.2017 um 22:53 schrieb Walter Parker:
>
>> On Mon, Dec 4, 2017 at 1:43 PM, Niklas Keller <me@kelunik.com> wrote:
>>
>>> and to be clear here:
>>>>
>>>> a client when connecting to a server configured like below has to
>>>> respect
>>>> the cipher order of the server while
>>>> https://www.ssllabs.com/ssltest/ exists for years to give dministrators
>>>> of the server some help and which clients are using which cipher
>>>>
>>>>
>>> Just minor nitpicking to get the facts right: A client does never respect
>>> the used cipher order of the server. A client offers a number of ciphers
>>> and the server chooses one of those, either based on its own order
>>> (preferred) or based on the client-preferred order.
>>>
>>> If you know other programs doing it better, research how they do it and
>>> propose a change to PHP please.
>>>
>>
> accepted, so PHP did only send a subset of the from openssl supported
> ciphers to the server not containing the modern ones
>
> That's good news. Given that openssl 1.1.0 only shipped late last year, I
>> fail to see how this has been an failure in PHP for many years for not
>> using a recent feature in openssl.
>> Looking at the sources for ab.c, it appears to do things like PHP. The
>> protocol level is hard coded to one value (SSL_METHOD
>> *SSLv23_method(void);)
>> There is a command line override (-Z protocol) that allows the protocol
>> selection to be changed to TLS1, TLS1.1, TLS1.2, or TLS1+TLS1.1+TLS1.2.
>>
>> Lists, could you please clarify what PHP should learn from how ab does
>> TLS?
>>
> as you can see in the ssllabs tests openssl 1.0.1 shipped years ago was
> able to use ECDHE/ECDSA with AES-GCM which is the recommended cipher, PHP
> until recent was only able to use "DHE-RSA-AES128-SHA", the first part is
> slow and the second part SHA1 is deprecated long ago for TLS
>
> PHP 7.1 even with openssl 1.1.x against MariaDB 10.2: ECDHE-RSA-AES128-SHA
>
> PHP 7.2 on the same environment: ECDHE-RSA-AES128-GCM-SHA256
> this was and is technically supported by openssl 1.0.x
>
> ssl-cipher = ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RS
> A-AES128-SHA"
>
> if you restrict mysqld to "ssl-cipher = ECDHE-RSA-AES128-GCM-SHA256"
> nothing before PHP 7.2.0 is able to connect at all
>
> at the same time "ab" which is a small 50 KB binary  supports ECDHE and
> AES-GCM ciphers for years and is also using openssl - it pretty sure gives
> a NULL as cipher to openssl which means openssl sends all it's supported
> ciphers to the server and the server then prefers the best one from his
> ordering due the handshake
>
> finally that means without touching the code around openssl from the
> moment on the openssl on the client side and the server supports and
> perefers a new cipher it will get used without touch "ab" and my question
> is why PHP is here completly differnt
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Oh, I see, this not about the actual change (the protocol version). This is
about when using PHP on the client side, it does not support all/enough of
the modern cipher suite list.

Now that we have identified the problem in question, this should help you
when you create your RFC to fix issues with the cipher suite list.

FYI, the client and server send lists of ciphers that they support to each
other, the server does an AND and picks the highest cipher in on the list.
If the client sends only NULL, then NULL is the only valid cipher. OpenSSL
has default list which includes weak ciphers (such as DES), so using the
default list is bad idea.

You keep using ab as your golden standard because it is small. I'd suggest
picking an application well known to be secure and not one based on the
fact that it is a small C program. I expect that ab gets the newer cipher
list by sending the large default list (which has both the strong items
with ECDHE & AES-GCM as well as DES and RC4). Server side, that would be a
major security issue.


Walter

-- 
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding.   -- Justice Louis D. Brandeis

--001a11c1342878ad35055f8ccb48--