Welcome! Log In Create A New Profile

Advanced

[PHP-DEV] PHP 7.2.0 Released

Posted by Remi Collet 
Remi Collet
[PHP-DEV] PHP 7.2.0 Released
November 30, 2017 12:10PM
The PHP development team announces the immediate availability of PHP
7.2.0. This release marks the second feature update to the PHP 7 series.

PHP 7.2.0 comes with numerous improvements and new features such as

- Convert numeric keys in object/array casts
- Counting of non-countable objects
- Object typehint
- HashContext as Object
- Argon2 in password hash
- Improve TLS constants to sane values
- Mcrypt extension removed
- New sodium extension

For source downloads of PHP 7.2.0 please visit our downloads page
Windows binaries can be found on the PHP for Windows site. The list of
changes is recorded in the ChangeLog.

The migration guide is available in the PHP Manual. Please consult it
for the detailed list of new features and backward incompatible changes.


Release Announcement: http://php.net/releases/7_2_0.php
Downloads: http://www.php.net/downloads
Windows downloads: http://windows.php.net/download
Changelog: http://www.php.net/ChangeLog-7.php#7.2.0
Migration guide: http://php.net/manual/en/migration72.php


Many thanks to all the contributors and supporters!

Sara Golemon, Remi Collet

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hannes Magnusson
Re: [PHP-DEV] PHP 7.2.0 Released
November 30, 2017 05:50PM
> - Improve TLS constants to sane values


This worries me a lot. Last time someone thought it was a good idea they
introduced security vulnerability for all apps that used them.

Do you have a link to this commit ?

-Hannes
Remi Collet
Re: [PHP-DEV] PHP 7.2.0 Released
November 30, 2017 06:10PM
Le 30/11/2017 à 17:41, Hannes Magnusson a écrit :

> Do you have a link to this commit ?

Simply following the link from the release notes...

https://wiki.php.net/rfc/improved-tls-constants



Remi

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Am 30.11.2017 um 17:41 schrieb Hannes Magnusson:
>> - Improve TLS constants to sane values
>
> This worries me a lot. Last time someone thought it was a good idea they
> introduced security vulnerability for all apps that used them.

that PHP now instead of ECDHE-RSA-AES128-SHA uses
ECDHE-RSA-AES128-GCM-SHA256 for TLS connections (and before 7.1 with
openssl 1.1 it was not able to use ECHDE at all) or that PHP don't let
the crypto library alone at all?

at least it got better with 7.2

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Niklas Keller
Re: [PHP-DEV] PHP 7.2.0 Released
December 01, 2017 05:50PM
lists@rhsoft.net <[email protected]> schrieb am Fr., 1. Dez. 2017, 17:13:

>
>
> Am 30.11.2017 um 17:41 schrieb Hannes Magnusson:
> >> - Improve TLS constants to sane values
> >
> > This worries me a lot. Last time someone thought it was a good idea they
> > introduced security vulnerability for all apps that used them.
>
> that PHP now instead of ECDHE-RSA-AES128-SHA uses
> ECDHE-RSA-AES128-GCM-SHA256 for TLS connections (and before 7.1 with
> openssl 1.1 it was not able to use ECHDE at all) or that PHP don't let
> the crypto library alone at all?
>
> at least it got better with 7.2
>

We only changed the defaults in 7.2, it was possible to use the same
features before, except for the security level.

Regards, Niklas

>
Am 01.12.2017 um 17:44 schrieb Niklas Keller:
> lists@rhsoft.net <mailto:[email protected]> <[email protected]
> <mailto:[email protected]>> schrieb am Fr., 1. Dez. 2017, 17:13:
>
>
>
> Am 30.11.2017 um 17:41 schrieb Hannes Magnusson:
> >> - Improve TLS constants to sane values
> >
> > This worries me a lot. Last time someone thought it was a good
> idea they
> > introduced security vulnerability for all apps that used them.
>
> that PHP now instead of ECDHE-RSA-AES128-SHA uses
> ECDHE-RSA-AES128-GCM-SHA256 for TLS connections (and before 7.1 with
> openssl 1.1 it was not able to use ECHDE at all) or that PHP don't let
> the crypto library alone at all?
>
> at least it got better with 7.2
>
> We only changed the defaults in 7.2, it was possible to use the same
> features before, except for the security level
yes and since nobody ever sould override the defaults in application
code for obvious reasons that's the problem, you shouldn't mangle with
openssl defaults in general and let openssl do the handshake which will
end in the server side perferred cipher and so in the most secure

what PHP does is making encryption weaker as it hsould be

above i talk about encrypted connection to mysqld

and *no* if our only cipher on the server is ECDHE-RSA-AES128-GCM-SHA256
anything before PHP 7.2 won't connect at all

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sara Golemon
Re: [PHP-DEV] PHP 7.2.0 Released
December 01, 2017 11:00PM
On Fri, Dec 1, 2017 at 11:52 AM, lists@rhsoft.net <[email protected]> wrote:
> yes and since nobody ever sould override the defaults in application code
> for obvious reasons that's the problem, you shouldn't mangle with openssl
> defaults in general and let openssl do the handshake which will end in the
> server side perferred cipher and so in the most secure
>
> what PHP does is making encryption weaker as it hsould be
>
Um. Did you look at the diff in question?

The old default was tls 1.0 only, the new default is tls 1.0, 1.1, or 1.2.
The new default allows OpenSSL to negotiate for a preferred method
where it couldn't before.
The change literally does the opposite of what you're talking about.

-Sara

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Am 01.12.2017 um 22:49 schrieb Sara Golemon:
> On Fri, Dec 1, 2017 at 11:52 AM, lists@rhsoft.net <[email protected]> wrote:
>> yes and since nobody ever sould override the defaults in application code
>> for obvious reasons that's the problem, you shouldn't mangle with openssl
>> defaults in general and let openssl do the handshake which will end in the
>> server side perferred cipher and so in the most secure
>>
>> what PHP does is making encryption weaker as it should be
>>
> Um. Did you look at the diff in question?
>
> The old default was tls 1.0 only, the new default is tls 1.0, 1.1, or 1.2.
> The new default allows OpenSSL to negotiate for a preferred method
> where it couldn't before.
> The change literally does the opposite of what you're talking about

for *now* and then when TLS 1.3 is out, the openssl on the system
supports TLS 1.3 PHP will hang on TLS1.2 as it did with TLS1.0?

the main question is why does PHP need to to *anything* here instead
hand the TLS handshake completly over to openssl? in that case even PHP5
could perfer TLS1.2 ciphers against a sevrer that orders them on top
without touch any line of PHP's code

"the opposite of what you're talking about" is plain wrong when you look
at my first response
_________________________

Am 30.11.2017 um 17:41 schrieb Hannes Magnusson:
>> - Improve TLS constants to sane values
>
> This worries me a lot. Last time someone thought it was a good
idea they
> introduced security vulnerability for all apps that used them.

that PHP now instead of ECDHE-RSA-AES128-SHA uses
ECDHE-RSA-AES128-GCM-SHA256 for TLS connections (and before 7.1 with
openssl 1.1 it was not able to use ECHDE at all) or that PHP don't let
the crypto library alone at all?

at least it got better with 7.2

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Walter Parker
Re: [PHP-DEV] PHP 7.2.0 Released
December 02, 2017 02:20AM
On Fri, Dec 1, 2017 at 3:35 PM, lists@rhsoft.net <[email protected]> wrote:

>
>
> Am 01.12.2017 um 22:49 schrieb Sara Golemon:
>
>> On Fri, Dec 1, 2017 at 11:52 AM, lists@rhsoft.net <[email protected]>
>> wrote:
>>
>>> yes and since nobody ever sould override the defaults in application code
>>> for obvious reasons that's the problem, you shouldn't mangle with openssl
>>> defaults in general and let openssl do the handshake which will end in
>>> the
>>> server side perferred cipher and so in the most secure
>>>
>>> what PHP does is making encryption weaker as it should be
>>>
>>> Um. Did you look at the diff in question?
>>
>> The old default was tls 1.0 only, the new default is tls 1.0, 1.1, or 1.2.
>> The new default allows OpenSSL to negotiate for a preferred method
>> where it couldn't before.
>> The change literally does the opposite of what you're talking about
>>
>
> for *now* and then when TLS 1.3 is out, the openssl on the system supports
> TLS 1.3 PHP will hang on TLS1.2 as it did with TLS1.0?
>
> the main question is why does PHP need to to *anything* here instead hand
> the TLS handshake completly over to openssl? in that case even PHP5 could
> perfer TLS1.2 ciphers against a sevrer that orders them on top without
> touch any line of PHP's code
>
> "the opposite of what you're talking about" is plain wrong when you look
> at my first response
> _________________________
>
> Am 30.11.2017 um 17:41 schrieb Hannes Magnusson:
> >> - Improve TLS constants to sane values
> >
> > This worries me a lot. Last time someone thought it was a good
> idea they
> > introduced security vulnerability for all apps that used them.
>
> that PHP now instead of ECDHE-RSA-AES128-SHA uses
> ECDHE-RSA-AES128-GCM-SHA256 for TLS connections (and before 7.1 with
> openssl 1.1 it was not able to use ECHDE at all) or that PHP don't let
> the crypto library alone at all?
>
> at least it got better with 7.2
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Lists, I fail to see how Sara was wrong and you are right.
In the old PHP, it was TLS 1.0
In the new PHP. it is TLS 1.2, TLS1.1, TLS1.3

When TLS1.3 comes out, old PHP will use only TLS1.0. <- This doesn't work
today for many sites
The new PHP will support TLS1.2, TLS 1.1, TLS 1.0 <- Still stronger that
the older version (required for many sites today)
When the openssl version that comes out to support the IETF final release
of TLS1.3 comes out in a few years, the openssl updates will be easier to
apply to the newest code base.

How many older PHP (5.X) systems will upgrade to (or even be able to
upgrade) to the newest openssl library?

As built right now, none of those would get TLS1.3 out of the box.

If you want the version selection moved completely to openssl, you should
write an RFC for that.

The current idea (where TLS1.3 is added to the list of defaults once the
software is release) vs an undefined system where it is handled magically
at a lower level doesn't appear to be more secure.


Walter


--
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis
Am 02.12.2017 um 02:08 schrieb Walter Parker:
> Lists, I fail to see how Sara was wrong and you are right.
> In the old PHP, it was TLS 1.0

bad enough

> In the new PHP. it is TLS 1.2, TLS1.1, TLS1.3

you surely meant 1.0 instead 1.3 here

> When TLS1.3 comes out, old PHP will use only TLS1.0. <- This doesn't work
> today for many sites

it should'nt have been used for *many* years

> The new PHP will support TLS1.2, TLS 1.1, TLS 1.0 <- Still stronger that
> the older version (required for many sites today)

yeah, but why do i need PHP 7.2 for get such basics right which openssl
and every other software on the system supports out-of-the-box for many
years?

> When the openssl version that comes out to support the IETF final release
> of TLS1.3 comes out in a few years, the openssl updates will be easier to
> apply to the newest code base.

and that's plain wrong - period

> How many older PHP (5.X) systems will upgrade to (or even be able to
> upgrade) to the newest openssl library?

they could have been used TLS1.2 years before PHP 7.2 was even
considered withgout that wrong design of how to hanlde TLS handshakes

> As built right now, none of those would get TLS1.3 out of the box.

beause nobody learnt from the past mistakes

> If you want the version selection moved completely to openssl, you should
> write an RFC for that.

that should have been common sense by doing the changes we are talking about

> The current idea (where TLS1.3 is added to the list of defaults once the
> software is release) vs an undefined system where it is handled magically
> at a lower level doesn't appear to be more secure

surely, openssl's job is to handle encryption and handsahkes, PHP failed
in this area proveable and has no bunsiness at all in that context

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sara Golemon
Re: [PHP-DEV] PHP 7.2.0 Released
December 04, 2017 06:40PM
On Fri, Dec 1, 2017 at 6:35 PM, lists@rhsoft.net <[email protected]> wrote:
> the main question is why does PHP need to to *anything* here instead hand
> the TLS handshake completly over to openssl? in that case even PHP5 could
> perfer TLS1.2 ciphers against a sevrer that orders them on top without touch
> any line of PHP's code
>
Because the SSL API in OpenSSL that PHP uses doesn't let you say:
"Just give me the best method you can".

SSL_CTX *SSL_CTX_new(const SSL_METHOD *method);
const SSL_METHOD *SSLv23_method(void);
const SSL_METHOD *SSLv23_server_method(void);
const SSL_METHOD *SSLv23_client_method(void);
const SSL_METHOD *TLSv1_2_method(void);
const SSL_METHOD *TLSv1_2_server_method(void);
const SSL_METHOD *TLSv1_2_client_method(void);
const SSL_METHOD *TLSv1_1_method(void);
const SSL_METHOD *TLSv1_1_server_method(void);
const SSL_METHOD *TLSv1_1_client_method(void);
const SSL_METHOD *TLSv1_method(void);
const SSL_METHOD *TLSv1_server_method(void);
const SSL_METHOD *TLSv1_client_method(void);
#ifndef OPENSSL_NO_SSL3_METHOD
const SSL_METHOD *SSLv3_method(void);
const SSL_METHOD *SSLv3_server_method(void);
const SSL_METHOD *SSLv3_client_method(void);
#endif
#ifndef OPENSSL_NO_SSL2
const SSL_METHOD *SSLv2_method(void);
const SSL_METHOD *SSLv2_server_method(void);
const SSL_METHOD *SSLv2_client_method(void);
#endif

There may be another SSL API that does, but that's more than just "set
the value to any and be done with it".

Pull requests welcome,
-Sara

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Am 04.12.2017 um 18:36 schrieb Sara Golemon:
> On Fri, Dec 1, 2017 at 6:35 PM, lists@rhsoft.net <[email protected]> wrote:
>> the main question is why does PHP need to to *anything* here instead hand
>> the TLS handshake completly over to openssl? in that case even PHP5 could
>> perfer TLS1.2 ciphers against a sevrer that orders them on top without touch
>> any line of PHP's code
>>
> Because the SSL API in OpenSSL that PHP uses doesn't let you say:
> "Just give me the best method you can"
>
> There may be another SSL API that does, but that's more than just "set
> the value to any and be done with it"

and how does other software like the apache benchmark tool "ab" this for
as long as i can think which is also linked against openssl?

[[email protected]:~]$ ab -c 1 -n 1 https://localhost/
This is ApacheBench, Version 2.3 <$Revision: 1807734 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient).....done

Server Software:
Server Hostname: localhost
Server Port: 443
SSL/TLS Protocol: TLSv1.2,ECDHE-ECDSA-AES128-GCM-SHA256,256,128
TLS Server Name: localhost
______________________

[[email protected]:~]$ ldd /usr/bin/ab
linux-vdso.so.1 (0x00007ffd015cc000)
libssl.so.1.1 => /lib64/libssl.so.1.1 (0x00007fb83e962000)
libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007fb83e4d7000)
libaprutil-1.so.0 => /lib64/libaprutil-1.so.0 (0x00007fb83ed96000)
libapr-1.so.0 => /lib64/libapr-1.so.0 (0x00007fb83ed5a000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fb83e2b8000)
libm.so.6 => /lib64/libm.so.6 (0x00007fb83dfa2000)
libc.so.6 => /lib64/libc.so.6 (0x00007fb83dbcd000)
libz.so.1 => /lib64/libz.so.1 (0x00007fb83d9b6000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fb83d7b2000)
libuuid.so.1 => /lib64/libuuid.so.1 (0x00007fb83d5ad000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007fb83d377000)
libexpat.so.1 => /lib64/libexpat.so.1 (0x00007fb83d144000)
/lib64/ld-linux-x86-64.so.2 (0x00007fb83ebce000)
libgomp.so.1 => /lib64/libgomp.so.1 (0x00007fb83cf15000)
libfreebl3.so => /lib64/libfreebl3.so (0x00007fb83cd12000)

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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

[[email protected]:~]$ openssl s_client -connect localhost:443
-servername localhost
..............
New, TLSv1.2, Cipher is ECDHE-ECDSA-AES128-GCM-SHA256
Server public key is 256 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-ECDSA-AES128-GCM-SHA256
________________________________________

Handshake Simulation for servers with ECDSA/RSA dual stack:
OpenSSL 1.0.1l R EC 256 (SHA256) TLS 1.2
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS
OpenSSL 1.0.2e R EC 256 (SHA256) TLS 1.2
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS
________________________________________

in case the server has only a RSA certificate:
OpenSSL 1.0.1l R RSA 2048 (SHA256) TLS 1.2
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS
OpenSSL 1.0.2e R RSA 2048 (SHA256) TLS 1.2
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS
________________________________________

SSLHonorCipherOrder On
SSLCipherSuite
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA


Am 04.12.2017 um 19:18 schrieb lists@rhsoft.net:
> Am 04.12.2017 um 18:36 schrieb Sara Golemon:
>> On Fri, Dec 1, 2017 at 6:35 PM, lists@rhsoft.net <[email protected]>
>> wrote:
>>> the main question is why does PHP need to to *anything* here instead
>>> hand
>>> the TLS handshake completly over to openssl? in that case even PHP5
>>> could
>>> perfer TLS1.2 ciphers against a sevrer that orders them on top
>>> without touch
>>> any line of PHP's code
>>>
>> Because the SSL API in OpenSSL that PHP uses doesn't let you say:
>> "Just give me the best method you can"
>>
>> There may be another SSL API that does, but that's more than just "set
>> the value to any and be done with it"
>
> and how does other software like the apache benchmark tool "ab" this for
> as long as i can think which is also linked against openssl?
>
> [[email protected]:~]$ ab -c 1 -n 1 https://localhost/
> This is ApacheBench, Version 2.3 <$Revision: 1807734 $>
> Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
> Licensed to The Apache Software Foundation, http://www.apache.org/
>
> Benchmarking localhost (be patient).....done
>
> Server Software:
> Server Hostname:        localhost
> Server Port:            443
> SSL/TLS Protocol:       TLSv1.2,ECDHE-ECDSA-AES128-GCM-SHA256,256,128
> TLS Server Name:        localhost
> ______________________
>
> [[email protected]:~]$ ldd /usr/bin/ab
>         linux-vdso.so.1 (0x00007ffd015cc000)
>         libssl.so.1.1 => /lib64/libssl.so.1.1 (0x00007fb83e962000)
>         libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007fb83e4d7000)
>         libaprutil-1.so.0 => /lib64/libaprutil-1.so.0 (0x00007fb83ed96000)
>         libapr-1.so.0 => /lib64/libapr-1.so.0 (0x00007fb83ed5a000)
>         libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fb83e2b8000)
>         libm.so.6 => /lib64/libm.so.6 (0x00007fb83dfa2000)
>         libc.so.6 => /lib64/libc.so.6 (0x00007fb83dbcd000)
>         libz.so.1 => /lib64/libz.so.1 (0x00007fb83d9b6000)
>         libdl.so.2 => /lib64/libdl.so.2 (0x00007fb83d7b2000)
>         libuuid.so.1 => /lib64/libuuid.so.1 (0x00007fb83d5ad000)
>         libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007fb83d377000)
>         libexpat.so.1 => /lib64/libexpat.so.1 (0x00007fb83d144000)
>         /lib64/ld-linux-x86-64.so.2 (0x00007fb83ebce000)
>         libgomp.so.1 => /lib64/libgomp.so.1 (0x00007fb83cf15000)
>         libfreebl3.so => /lib64/libfreebl3.so (0x00007fb83cd12000)
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sara Golemon
Re: [PHP-DEV] PHP 7.2.0 Released
December 04, 2017 09:00PM
On Mon, Dec 4, 2017 at 1:18 PM, lists@rhsoft.net <[email protected]> wrote:
> Am 04.12.2017 um 18:36 schrieb Sara Golemon:
>> On Fri, Dec 1, 2017 at 6:35 PM, lists@rhsoft.net <[email protected]> wrote:
>>>
>>> the main question is why does PHP need to to *anything* here instead hand
>>> the TLS handshake completly over to openssl? in that case even PHP5 could
>>> perfer TLS1.2 ciphers against a sevrer that orders them on top without
>>> touch
>>> any line of PHP's code
>>>
>> Because the SSL API in OpenSSL that PHP uses doesn't let you say:
>> "Just give me the best method you can"
>>
>> There may be another SSL API that does, but that's more than just "set
>> the value to any and be done with it"
>
>
> and how does other software like the apache benchmark tool "ab" this for as
> long as i can think which is also linked against openssl?
>

You quoted this, but I don't think you understood it.
"""
There may be another SSL API that does, but that's more than just "set
the value to any and be done with it".

Pull requests welcome,
"""

I don't doubt that it's possible to do, but it's not as trivial as
"Just make the ANY constant really mean ANY".
If you have a solution, offer it.
Until then, it's going to wait until someone else has the time and
inclination to do so.

-Sara

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Jakub Zelenka
Re: [PHP-DEV] PHP 7.2.0 Released
December 04, 2017 10:40PM
On Mon, Dec 4, 2017 at 5:36 PM, Sara Golemon <[email protected]> wrote:

> On Fri, Dec 1, 2017 at 6:35 PM, lists@rhsoft.net <[email protected]> wrote:
> > the main question is why does PHP need to to *anything* here instead hand
> > the TLS handshake completly over to openssl? in that case even PHP5 could
> > perfer TLS1.2 ciphers against a sevrer that orders them on top without
> touch
> > any line of PHP's code
> >
> Because the SSL API in OpenSSL that PHP uses doesn't let you say:
> "Just give me the best method you can".
>
> SSL_CTX *SSL_CTX_new(const SSL_METHOD *method);
> const SSL_METHOD *SSLv23_method(void);
> const SSL_METHOD *SSLv23_server_method(void);
> const SSL_METHOD *SSLv23_client_method(void);
> const SSL_METHOD *TLSv1_2_method(void);
> const SSL_METHOD *TLSv1_2_server_method(void);
> const SSL_METHOD *TLSv1_2_client_method(void);
> const SSL_METHOD *TLSv1_1_method(void);
> const SSL_METHOD *TLSv1_1_server_method(void);
> const SSL_METHOD *TLSv1_1_client_method(void);
> const SSL_METHOD *TLSv1_method(void);
> const SSL_METHOD *TLSv1_server_method(void);
> const SSL_METHOD *TLSv1_client_method(void);
> #ifndef OPENSSL_NO_SSL3_METHOD
> const SSL_METHOD *SSLv3_method(void);
> const SSL_METHOD *SSLv3_server_method(void);
> const SSL_METHOD *SSLv3_client_method(void);
> #endif
> #ifndef OPENSSL_NO_SSL2
> const SSL_METHOD *SSLv2_method(void);
> const SSL_METHOD *SSLv2_server_method(void);
> const SSL_METHOD *SSLv2_client_method(void);
> #endif
>
> There may be another SSL API that does, but that's more than just "set
> the value to any and be done with it".
>

Yep there is SSL_CTX_set_min_proto_version
and SSL_CTX_set_max_proto_version in OpenSSL 1.1.0+ which is the preferred
way how to set the protocol. The version specific method are all now
deprecated and should not be used. I have got it on my TODO list so
hopefully will find time to implement it. It would be ideal to just
introduce min and max protocol version context options for tls and possibly
ssl (which is tls alias now) streams. It is of course backportable to 1.0.1
and 1.0.2 using SSL_OP_NO_* which is how it is basically working now but
for 1.1.0+ it will use more flexible min and max. I think it would also
make sense to deprecate tlsv* and sslv* streams but don't feel so strongly
about it.

The c part implementation is not too difficult but we should probably
improve and extend the version tests (that are really slow atm.) so it
might take a bit. Anyway I really hope to have it in 7.3.

Cheers

Jakub
Niklas Keller
Re: [PHP-DEV] PHP 7.2.0 Released
December 04, 2017 10:50PM
>
> 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.

Regards, Niklas
Walter Parker
Re: [PHP-DEV] PHP 7.2.0 Released
December 04, 2017 11:00PM
On Mon, Dec 4, 2017 at 1:43 PM, Niklas Keller <[email protected]> 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.
>
> Regards, Niklas
>

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?


Walter



--
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis
Am 04.12.2017 um 22:53 schrieb Walter Parker:
> On Mon, Dec 4, 2017 at 1:43 PM, Niklas Keller <[email protected]> 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-RSA-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
Walter Parker
Re: [PHP-DEV] PHP 7.2.0 Released
December 05, 2017 01:30AM
On Mon, Dec 4, 2017 at 2:21 PM, lists@rhsoft.net <[email protected]> wrote:

>
>
> Am 04.12.2017 um 22:53 schrieb Walter Parker:
>
>> On Mon, Dec 4, 2017 at 1:43 PM, Niklas Keller <[email protected]> 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
Am 05.12.2017 um 01:19 schrieb Walter Parker:
> 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

this is not true at all and that's why you use tools like
https://www.ssllabs.com/ssltest/ and SSLHonorCipherOrder as serveradmin
for many years if you care about TLS at all

also the default openssl cipherlist is not just random

as you can see it prefers the ECDSA AES-GCM followed by the RSA AES-GCM
and after the ECDHE it continues with other GCM ciphers na dthe DES/CBC
stuff is at a place in the list which never is selected these days

[[email protected]:~]$ openssl ciphers -v
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA
Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256)
Mac=AEAD
ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=ECDSA
Enc=CHACHA20/POLY1305(256) Mac=AEAD
ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=RSA
Enc=CHACHA20/POLY1305(256) Mac=AEAD
ECDHE-ECDSA-AES256-CCM8 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESCCM8(256)
Mac=AEAD
ECDHE-ECDSA-AES256-CCM TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESCCM(256)
Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA
Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128)
Mac=AEAD
ECDHE-ECDSA-AES128-CCM8 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESCCM8(128)
Mac=AEAD
ECDHE-ECDSA-AES128-CCM TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESCCM(128)
Mac=AEAD
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256)
Mac=SHA384
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384
ECDHE-ECDSA-CAMELLIA256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA
Enc=Camellia(256) Mac=SHA384
ECDHE-RSA-CAMELLIA256-SHA384 TLSv1.2 Kx=ECDH Au=RSA
Enc=Camellia(256) Mac=SHA384


ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128)
Mac=SHA256

ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128)
Mac=SHA256

ECDHE-ECDSA-CAMELLIA128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA
Enc=Camellia(128) Mac=SHA256


ECDHE-RSA-CAMELLIA128-SHA256 TLSv1.2 Kx=ECDH Au=RSA
Enc=Camellia(128) Mac=SHA256


ECDHE-ECDSA-AES256-SHA TLSv1 Kx=ECDH Au=ECDSA Enc=AES(256)
Mac=SHA1

ECDHE-RSA-AES256-SHA TLSv1 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1


ECDHE-ECDSA-AES128-SHA TLSv1 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA1
ECDHE-RSA-AES128-SHA TLSv1 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1
ECDHE-ECDSA-DES-CBC3-SHA TLSv1 Kx=ECDH Au=ECDSA Enc=3DES(168) Mac=SHA1
ECDHE-RSA-DES-CBC3-SHA TLSv1 Kx=ECDH Au=RSA Enc=3DES(168) Mac=SHA1
AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD
AES256-CCM8 TLSv1.2 Kx=RSA Au=RSA Enc=AESCCM8(256)
Mac=AEAD
AES256-CCM TLSv1.2 Kx=RSA Au=RSA Enc=AESCCM(256) Mac=AEAD
AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD
AES128-CCM8 TLSv1.2 Kx=RSA Au=RSA Enc=AESCCM8(128)
Mac=AEAD
AES128-CCM TLSv1.2 Kx=RSA Au=RSA Enc=AESCCM(128) Mac=AEAD
AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256
CAMELLIA256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=Camellia(256)
Mac=SHA256
AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256
CAMELLIA128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=Camellia(128)
Mac=SHA256
AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
CAMELLIA256-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(256) Mac=SHA1
AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1
CAMELLIA128-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(128) Mac=SHA1
DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1
DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(256)
Mac=AEAD
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256)
Mac=AEAD
DHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=DH Au=RSA
Enc=CHACHA20/POLY1305(256) Mac=AEAD
DHE-RSA-AES256-CCM8 TLSv1.2 Kx=DH Au=RSA Enc=AESCCM8(256)
Mac=AEAD
DHE-RSA-AES256-CCM TLSv1.2 Kx=DH Au=RSA Enc=AESCCM(256) Mac=AEAD
DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(128)
Mac=AEAD
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128)
Mac=AEAD
DHE-RSA-AES128-CCM8 TLSv1.2 Kx=DH Au=RSA Enc=AESCCM8(128)
Mac=AEAD
DHE-RSA-AES128-CCM TLSv1.2 Kx=DH Au=RSA Enc=AESCCM(128) Mac=AEAD
DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256
DHE-DSS-AES256-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(256) Mac=SHA256
DHE-RSA-CAMELLIA256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=Camellia(256)
Mac=SHA256
DHE-DSS-CAMELLIA256-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=Camellia(256)
Mac=SHA256
DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256
DHE-DSS-AES128-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(128) Mac=SHA256
DHE-RSA-CAMELLIA128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=Camellia(128)
Mac=SHA256
DHE-DSS-CAMELLIA128-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=Camellia(128)
Mac=SHA256
DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1
DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1
DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(256) Mac=SHA1
DHE-DSS-CAMELLIA256-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(256) Mac=SHA1
DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1
DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1
DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(128) Mac=SHA1
DHE-DSS-CAMELLIA128-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(128) Mac=SHA1
DHE-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1
DHE-DSS-DES-CBC3-SHA SSLv3 Kx=DH Au=DSS Enc=3DES(168) Mac=SHA1
PSK-AES256-GCM-SHA384 TLSv1.2 Kx=PSK Au=PSK Enc=AESGCM(256) Mac=AEAD
PSK-CHACHA20-POLY1305 TLSv1.2 Kx=PSK Au=PSK
Enc=CHACHA20/POLY1305(256) Mac=AEAD
PSK-AES256-CCM8 TLSv1.2 Kx=PSK Au=PSK Enc=AESCCM8(256)
Mac=AEAD
PSK-AES256-CCM TLSv1.2 Kx=PSK Au=PSK Enc=AESCCM(256) Mac=AEAD
PSK-AES128-GCM-SHA256 TLSv1.2 Kx=PSK Au=PSK Enc=AESGCM(128) Mac=AEAD
PSK-AES128-CCM8 TLSv1.2 Kx=PSK Au=PSK Enc=AESCCM8(128)
Mac=AEAD
PSK-AES128-CCM TLSv1.2 Kx=PSK Au=PSK Enc=AESCCM(128) Mac=AEAD
PSK-AES256-CBC-SHA384 TLSv1 Kx=PSK Au=PSK Enc=AES(256) Mac=SHA384
PSK-AES256-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=AES(256) Mac=SHA1
PSK-CAMELLIA256-SHA384 TLSv1 Kx=PSK Au=PSK Enc=Camellia(256)
Mac=SHA384
PSK-AES128-CBC-SHA256 TLSv1 Kx=PSK Au=PSK Enc=AES(128) Mac=SHA256
PSK-AES128-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=AES(128) Mac=SHA1
PSK-CAMELLIA128-SHA256 TLSv1 Kx=PSK Au=PSK Enc=Camellia(128)
Mac=SHA256
PSK-3DES-EDE-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=3DES(168) Mac=SHA1
DHE-PSK-AES256-GCM-SHA384 TLSv1.2 Kx=DHEPSK Au=PSK Enc=AESGCM(256)
Mac=AEAD
DHE-PSK-CHACHA20-POLY1305 TLSv1.2 Kx=DHEPSK Au=PSK
Enc=CHACHA20/POLY1305(256) Mac=AEAD
DHE-PSK-AES256-CCM8 TLSv1.2 Kx=DHEPSK Au=PSK Enc=AESCCM8(256)
Mac=AEAD
DHE-PSK-AES256-CCM TLSv1.2 Kx=DHEPSK Au=PSK Enc=AESCCM(256) Mac=AEAD
DHE-PSK-AES128-GCM-SHA256 TLSv1.2 Kx=DHEPSK Au=PSK Enc=AESGCM(128)
Mac=AEAD
DHE-PSK-AES128-CCM8 TLSv1.2 Kx=DHEPSK Au=PSK Enc=AESCCM8(128)
Mac=AEAD
DHE-PSK-AES128-CCM TLSv1.2 Kx=DHEPSK Au=PSK Enc=AESCCM(128) Mac=AEAD
DHE-PSK-AES256-CBC-SHA384 TLSv1 Kx=DHEPSK Au=PSK Enc=AES(256) Mac=SHA384
DHE-PSK-AES256-CBC-SHA SSLv3 Kx=DHEPSK Au=PSK Enc=AES(256) Mac=SHA1
DHE-PSK-CAMELLIA256-SHA384 TLSv1 Kx=DHEPSK Au=PSK Enc=Camellia(256)
Mac=SHA384
DHE-PSK-AES128-CBC-SHA256 TLSv1 Kx=DHEPSK Au=PSK Enc=AES(128) Mac=SHA256
DHE-PSK-AES128-CBC-SHA SSLv3 Kx=DHEPSK Au=PSK Enc=AES(128) Mac=SHA1
DHE-PSK-CAMELLIA128-SHA256 TLSv1 Kx=DHEPSK Au=PSK Enc=Camellia(128)
Mac=SHA256
DHE-PSK-3DES-EDE-CBC-SHA SSLv3 Kx=DHEPSK Au=PSK Enc=3DES(168) Mac=SHA1
ECDHE-PSK-CHACHA20-POLY1305 TLSv1.2 Kx=ECDHEPSK Au=PSK
Enc=CHACHA20/POLY1305(256) Mac=AEAD
ECDHE-PSK-AES256-CBC-SHA384 TLSv1 Kx=ECDHEPSK Au=PSK Enc=AES(256)
Mac=SHA384
ECDHE-PSK-AES256-CBC-SHA TLSv1 Kx=ECDHEPSK Au=PSK Enc=AES(256) Mac=SHA1
ECDHE-PSK-CAMELLIA256-SHA384 TLSv1 Kx=ECDHEPSK Au=PSK Enc=Camellia(256)
Mac=SHA384
ECDHE-PSK-AES128-CBC-SHA256 TLSv1 Kx=ECDHEPSK Au=PSK Enc=AES(128)
Mac=SHA256
ECDHE-PSK-AES128-CBC-SHA TLSv1 Kx=ECDHEPSK Au=PSK Enc=AES(128) Mac=SHA1
ECDHE-PSK-CAMELLIA128-SHA256 TLSv1 Kx=ECDHEPSK Au=PSK Enc=Camellia(128)
Mac=SHA256
ECDHE-PSK-3DES-EDE-CBC-SHA TLSv1 Kx=ECDHEPSK Au=PSK Enc=3DES(168) Mac=SHA1



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Walter Parker
Re: [PHP-DEV] PHP 7.2.0 Released
December 05, 2017 07:00AM
On Mon, Dec 4, 2017 at 6:27 PM, lists@rhsoft.net <[email protected]> wrote:

>
>
> Am 05.12.2017 um 01:19 schrieb Walter Parker:
>
>> 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
>>
>
> this is not true at all and that's why you use tools like
> https://www.ssllabs.com/ssltest/ and SSLHonorCipherOrder as serveradmin
> for many years if you care about TLS at all
>
> also the default openssl cipherlist is not just random
>
> as you can see it prefers the ECDSA AES-GCM followed by the RSA AES-GCM
> and after the ECDHE it continues with other GCM ciphers na dthe DES/CBC
> stuff is at a place in the list which never is selected these days
>
> [[email protected]:~]$ openssl ciphers -v
> ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256)
> Mac=AEAD
> ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256)
> Mac=AEAD
> ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=ECDSA
> Enc=CHACHA20/POLY1305(256) Mac=AEAD
> ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=RSA
> Enc=CHACHA20/POLY1305(256) Mac=AEAD
> ECDHE-ECDSA-AES256-CCM8 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESCCM8(256)
> Mac=AEAD
> ECDHE-ECDSA-AES256-CCM TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESCCM(256)
> Mac=AEAD
> ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128)
> Mac=AEAD
> ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128)
> Mac=AEAD
> ECDHE-ECDSA-AES128-CCM8 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESCCM8(128)
> Mac=AEAD
> ECDHE-ECDSA-AES128-CCM TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESCCM(128)
> Mac=AEAD
> ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256)
> Mac=SHA384
> ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256)
> Mac=SHA384
> ECDHE-ECDSA-CAMELLIA256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA
> Enc=Camellia(256) Mac=SHA384
> ECDHE-RSA-CAMELLIA256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=Camellia(256)
> Mac=SHA384
>
> ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128)
> Mac=SHA256
> ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128)
> Mac=SHA256
> ECDHE-ECDSA-CAMELLIA128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA
> Enc=Camellia(128) Mac=SHA256
>
> ECDHE-RSA-CAMELLIA128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=Camellia(128)
> Mac=SHA256
>
> ECDHE-ECDSA-AES256-SHA TLSv1 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA1
> ECDHE-RSA-AES256-SHA TLSv1 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1
>
> ECDHE-ECDSA-AES128-SHA TLSv1 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA1
> ECDHE-RSA-AES128-SHA TLSv1 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1
> ECDHE-ECDSA-DES-CBC3-SHA TLSv1 Kx=ECDH Au=ECDSA Enc=3DES(168) Mac=SHA1
> ECDHE-RSA-DES-CBC3-SHA TLSv1 Kx=ECDH Au=RSA Enc=3DES(168) Mac=SHA1
> AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256)
> Mac=AEAD
> AES256-CCM8 TLSv1.2 Kx=RSA Au=RSA Enc=AESCCM8(256)
> Mac=AEAD
> AES256-CCM TLSv1.2 Kx=RSA Au=RSA Enc=AESCCM(256)
> Mac=AEAD
> AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128)
> Mac=AEAD
> AES128-CCM8 TLSv1.2 Kx=RSA Au=RSA Enc=AESCCM8(128)
> Mac=AEAD
> AES128-CCM TLSv1.2 Kx=RSA Au=RSA Enc=AESCCM(128)
> Mac=AEAD
> AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256)
> Mac=SHA256
> CAMELLIA256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=Camellia(256)
> Mac=SHA256
> AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128)
> Mac=SHA256
> CAMELLIA128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=Camellia(128)
> Mac=SHA256
> AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
> CAMELLIA256-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(256)
> Mac=SHA1
> AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1
> CAMELLIA128-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(128)
> Mac=SHA1
> DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1
> DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(256)
> Mac=AEAD
> DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256)
> Mac=AEAD
> DHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=DH Au=RSA
> Enc=CHACHA20/POLY1305(256) Mac=AEAD
> DHE-RSA-AES256-CCM8 TLSv1.2 Kx=DH Au=RSA Enc=AESCCM8(256)
> Mac=AEAD
> DHE-RSA-AES256-CCM TLSv1.2 Kx=DH Au=RSA Enc=AESCCM(256)
> Mac=AEAD
> DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(128)
> Mac=AEAD
> DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128)
> Mac=AEAD
> DHE-RSA-AES128-CCM8 TLSv1.2 Kx=DH Au=RSA Enc=AESCCM8(128)
> Mac=AEAD
> DHE-RSA-AES128-CCM TLSv1.2 Kx=DH Au=RSA Enc=AESCCM(128)
> Mac=AEAD
> DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256)
> Mac=SHA256
> DHE-DSS-AES256-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(256)
> Mac=SHA256
> DHE-RSA-CAMELLIA256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=Camellia(256)
> Mac=SHA256
> DHE-DSS-CAMELLIA256-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=Camellia(256)
> Mac=SHA256
> DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128)
> Mac=SHA256
> DHE-DSS-AES128-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(128)
> Mac=SHA256
> DHE-RSA-CAMELLIA128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=Camellia(128)
> Mac=SHA256
> DHE-DSS-CAMELLIA128-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=Camellia(128)
> Mac=SHA256
> DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1
> DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1
> DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(256)
> Mac=SHA1
> DHE-DSS-CAMELLIA256-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(256)
> Mac=SHA1
> DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1
> DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1
> DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(128)
> Mac=SHA1
> DHE-DSS-CAMELLIA128-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(128)
> Mac=SHA1
> DHE-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1
> DHE-DSS-DES-CBC3-SHA SSLv3 Kx=DH Au=DSS Enc=3DES(168) Mac=SHA1
> PSK-AES256-GCM-SHA384 TLSv1.2 Kx=PSK Au=PSK Enc=AESGCM(256)
> Mac=AEAD
> PSK-CHACHA20-POLY1305 TLSv1.2 Kx=PSK Au=PSK
> Enc=CHACHA20/POLY1305(256) Mac=AEAD
> PSK-AES256-CCM8 TLSv1.2 Kx=PSK Au=PSK Enc=AESCCM8(256)
> Mac=AEAD
> PSK-AES256-CCM TLSv1.2 Kx=PSK Au=PSK Enc=AESCCM(256)
> Mac=AEAD
> PSK-AES128-GCM-SHA256 TLSv1.2 Kx=PSK Au=PSK Enc=AESGCM(128)
> Mac=AEAD
> PSK-AES128-CCM8 TLSv1.2 Kx=PSK Au=PSK Enc=AESCCM8(128)
> Mac=AEAD
> PSK-AES128-CCM TLSv1.2 Kx=PSK Au=PSK Enc=AESCCM(128)
> Mac=AEAD
> PSK-AES256-CBC-SHA384 TLSv1 Kx=PSK Au=PSK Enc=AES(256) Mac=SHA384
> PSK-AES256-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=AES(256) Mac=SHA1
> PSK-CAMELLIA256-SHA384 TLSv1 Kx=PSK Au=PSK Enc=Camellia(256)
> Mac=SHA384
> PSK-AES128-CBC-SHA256 TLSv1 Kx=PSK Au=PSK Enc=AES(128) Mac=SHA256
> PSK-AES128-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=AES(128) Mac=SHA1
> PSK-CAMELLIA128-SHA256 TLSv1 Kx=PSK Au=PSK Enc=Camellia(128)
> Mac=SHA256
> PSK-3DES-EDE-CBC-SHA SSLv3 Kx=PSK Au=PSK Enc=3DES(168) Mac=SHA1
> DHE-PSK-AES256-GCM-SHA384 TLSv1.2 Kx=DHEPSK Au=PSK Enc=AESGCM(256)
> Mac=AEAD
> DHE-PSK-CHACHA20-POLY1305 TLSv1.2 Kx=DHEPSK Au=PSK
> Enc=CHACHA20/POLY1305(256) Mac=AEAD
> DHE-PSK-AES256-CCM8 TLSv1.2 Kx=DHEPSK Au=PSK Enc=AESCCM8(256)
> Mac=AEAD
> DHE-PSK-AES256-CCM TLSv1.2 Kx=DHEPSK Au=PSK Enc=AESCCM(256)
> Mac=AEAD
> DHE-PSK-AES128-GCM-SHA256 TLSv1.2 Kx=DHEPSK Au=PSK Enc=AESGCM(128)
> Mac=AEAD
> DHE-PSK-AES128-CCM8 TLSv1.2 Kx=DHEPSK Au=PSK Enc=AESCCM8(128)
> Mac=AEAD
> DHE-PSK-AES128-CCM TLSv1.2 Kx=DHEPSK Au=PSK Enc=AESCCM(128)
> Mac=AEAD
> DHE-PSK-AES256-CBC-SHA384 TLSv1 Kx=DHEPSK Au=PSK Enc=AES(256)
> Mac=SHA384
> DHE-PSK-AES256-CBC-SHA SSLv3 Kx=DHEPSK Au=PSK Enc=AES(256) Mac=SHA1
> DHE-PSK-CAMELLIA256-SHA384 TLSv1 Kx=DHEPSK Au=PSK Enc=Camellia(256)
> Mac=SHA384
> DHE-PSK-AES128-CBC-SHA256 TLSv1 Kx=DHEPSK Au=PSK Enc=AES(128)
> Mac=SHA256
> DHE-PSK-AES128-CBC-SHA SSLv3 Kx=DHEPSK Au=PSK Enc=AES(128) Mac=SHA1
> DHE-PSK-CAMELLIA128-SHA256 TLSv1 Kx=DHEPSK Au=PSK Enc=Camellia(128)
> Mac=SHA256
> DHE-PSK-3DES-EDE-CBC-SHA SSLv3 Kx=DHEPSK Au=PSK Enc=3DES(168) Mac=SHA1
> ECDHE-PSK-CHACHA20-POLY1305 TLSv1.2 Kx=ECDHEPSK Au=PSK
> Enc=CHACHA20/POLY1305(256) Mac=AEAD
> ECDHE-PSK-AES256-CBC-SHA384 TLSv1 Kx=ECDHEPSK Au=PSK Enc=AES(256)
> Mac=SHA384
> ECDHE-PSK-AES256-CBC-SHA TLSv1 Kx=ECDHEPSK Au=PSK Enc=AES(256) Mac=SHA1
> ECDHE-PSK-CAMELLIA256-SHA384 TLSv1 Kx=ECDHEPSK Au=PSK Enc=Camellia(256)
> Mac=SHA384
> ECDHE-PSK-AES128-CBC-SHA256 TLSv1 Kx=ECDHEPSK Au=PSK Enc=AES(128)
> Mac=SHA256
> ECDHE-PSK-AES128-CBC-SHA TLSv1 Kx=ECDHEPSK Au=PSK Enc=AES(128) Mac=SHA1
> ECDHE-PSK-CAMELLIA128-SHA256 TLSv1 Kx=ECDHEPSK Au=PSK Enc=Camellia(128)
> Mac=SHA256
> ECDHE-PSK-3DES-EDE-CBC-SHA TLSv1 Kx=ECDHEPSK Au=PSK Enc=3DES(168) Mac=SHA1
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
> Your link doesn't say what you think it does. Your follow up comments also
appear to have little relevance to the topic at hand.

Could someone please let me know if Lists ever get back on topic with
responses to the questions and statements made, rather than charging
sideways off the field?

Thanks!



--
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis
Am 05.12.2017 um 06:52 schrieb Walter Parker:
> On Mon, Dec 4, 2017 at 6:27 PM, lists@rhsoft.net
> <mailto:[email protected]> <[email protected] <mailto:[email protected]>>
> wrote:
>
> Am 05.12.2017 um 01:19 schrieb Walter Parker:
>
> 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
>
> this is not true at all and that's why you use tools like
> https://www.ssllabs.com/ssltest/
> and SSLHonorCipherOrder as serveradmin for many years if you care
> about TLS at all
>
> also the default openssl cipherlist is not just random
>
> as you can see it prefers the ECDSA AES-GCM followed by the RSA
> AES-GCM and after the ECDHE it continues with other GCM ciphers na
> dthe DES/CBC stuff is at a place in the list which never is selected
> these days
>
> Your link doesn't say what you think it does

which one?
https://www.ssllabs.com/ssltest/

sorry, but if you don't know what ssllab does and how it is used by
serveradmins to make sure clients using best possible encryption you are
hardly in the position making comments like "OpenSSL has default list
which includes weak ciphers (such as DES), so using the default list is
bad idea" and instead abusive responses you could have entered the url
of a TLS webserver

> Your follow up comments
> also appear to have little relevance to the topic at hand.

correct and the reason is that i needed to give you some basic education
how ciphers in the real world are negotiated

> Could someone please let me know if Lists ever get back on topic with
> responses to the questions and statements made, rather than charging
> sideways off the field?
go and provocate someone else when you make clueless statements like
"OpenSSL has default list which includes weak ciphers (such as DES), so
using the default list is bad idea"

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Walter Parker
Re: [PHP-DEV] PHP 7.2.0 Released
December 05, 2017 05:50PM
On Tue, Dec 5, 2017 at 12:54 AM, lists@rhsoft.net <[email protected]> wrote:

>
>
> Am 05.12.2017 um 06:52 schrieb Walter Parker:
>
>> On Mon, Dec 4, 2017 at 6:27 PM, lists@rhsoft.net <mailto:[email protected]>
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>> Am 05.12.2017 um 01:19 schrieb Walter Parker:
>>
>> 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
>>
>> this is not true at all and that's why you use tools like
>> https://www.ssllabs.com/ssltest/ and SSLHonorCipherOrder as
>> serveradmin for many years if you care
>> about TLS at all
>>
>> also the default openssl cipherlist is not just random
>>
>> as you can see it prefers the ECDSA AES-GCM followed by the RSA
>> AES-GCM and after the ECDHE it continues with other GCM ciphers na
>> dthe DES/CBC stuff is at a place in the list which never is selected
>> these days
>>
>> Your link doesn't say what you think it does
>>
>
> which one?
> https://www.ssllabs.com/ssltest/
>
> sorry, but if you don't know what ssllab does and how it is used by
> serveradmins to make sure clients using best possible encryption you are
> hardly in the position making comments like "OpenSSL has default list which
> includes weak ciphers (such as DES), so using the default list is bad idea"
> and instead abusive responses you could have entered the url of a TLS
> webserver
>
> Your follow up comments also appear to have little relevance to the topic
>> at hand.
>>
>
> correct and the reason is that i needed to give you some basic education
> how ciphers in the real world are negotiated
>
> Could someone please let me know if Lists ever get back on topic with
>> responses to the questions and statements made, rather than charging
>> sideways off the field?
>>
> go and provocate someone else when you make clueless statements like
> "OpenSSL has default list which includes weak ciphers (such as DES), so
> using the default list is bad idea"
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
> Lists, I give you the same advice. I know and use SSL Labs, I been a
subscriber to Ivan's mailing list for years. Older versions of Openssl had
a default list of +ALL, -aNULL, -eNULL as the default list of ciphers.
Before DES was removed in the new versions of openssl, that means the list
included things like DES and RC4. That is why server admins always spelled
out long lists of ciphers, to guarantee that weak ciphers would not appear
on older installs. I found this information by reading the code bases
themselves, where did you find your information?

I'm done with you. You don't understand and worse you don't want to
understand but think you understand. You just admitted to that. Please stop
until you get proper training as someone else on this list might make the
same mistakes that you are.



--
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis
Am 05.12.2017 um 17:45 schrieb Walter Parker:
> Lists, I give you the same advice. I know and use SSL Labs, I been a
> subscriber to Ivan's mailing list for years. Older versions of Openssl
> had a default list of +ALL, -aNULL, -eNULL as the default list of
> ciphers

yes

> Before DES was removed in the new versions of openssl, that
> means the list included things like DES and RC4

don't matter because no somehow recent client would have negotiated
DES/RC4 with a config like below even if the SSLCipherSuite would
contain RC4/DES at the end of the list

SSLHonorCipherOrder On
SSLCipherSuite
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA

> That is why server
> admins always spelled out long lists of ciphers, to guarantee that weak
> ciphers would not appear on older installs. I found this information by
> reading the code bases themselves, where did you find your information?

frankly you are saying exactly the same as i did

the point is that for nearly a deacde servers take care of negotiated
ciphers and when tomorrow one of them like AES-CBC with several
vulerabilities in the past years becomes problematic like you even was
advised to prefer RC4 instead block-ciphers for the timewinodow of a
large amount unfixed clients you can as serveradmin migitate the problem

but only if the client is not PHP which thinks to outsmart client
openssl as well as servers configuration

this also makes initiatives like
https://fedoraproject.org/wiki/Changes/CryptoPolicy useless and
everything reacts faster than wait for the next PHP point release!

> I'm done with you. You don't understand and worse you don't want to
> understand but think you understand. You just admitted to that. Please
> stop until you get proper training as someone else on this list might
> make the same mistakes that you are
yes, please stop to repsond to any of my mails, especially stop offlist
mails

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Walter Parker
Re: [PHP-DEV] PHP 7.2.0 Released
December 05, 2017 06:40PM
Deleted without reading...

On Tue, Dec 5, 2017 at 9:09 AM, lists@rhsoft.net <[email protected]> wrote:

>
>
> Am 05.12.2017 um 17:45 schrieb Walter Parker:
>
>> Lists, I give you the same advice. I know and use SSL Labs, I been a
>> subscriber to Ivan's mailing list for years. Older versions of Openssl had
>> a default list of +ALL, -aNULL, -eNULL as the default list of ciphers
>>
>
> yes
>
> Before DES was removed in the new versions of openssl, that means the list
>> included things like DES and RC4
>>
>
> don't matter because no somehow recent client would have negotiated
> DES/RC4 with a config like below even if the SSLCipherSuite would contain
> RC4/DES at the end of the list
>
> SSLHonorCipherOrder On
> SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:
> ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:
> ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-CHACHA20-POLY1305:ECDH
> E-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-
> ECDSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-
> AES256-SHA384:ECDHE-ECDSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA:
> ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-
> GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-SHA256:
> DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:
> AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA
>
> That is why server admins always spelled out long lists of ciphers, to
>> guarantee that weak ciphers would not appear on older installs. I found
>> this information by reading the code bases themselves, where did you find
>> your information?
>>
>
> frankly you are saying exactly the same as i did
>
> the point is that for nearly a deacde servers take care of negotiated
> ciphers and when tomorrow one of them like AES-CBC with several
> vulerabilities in the past years becomes problematic like you even was
> advised to prefer RC4 instead block-ciphers for the timewinodow of a large
> amount unfixed clients you can as serveradmin migitate the problem
>
> but only if the client is not PHP which thinks to outsmart client openssl
> as well as servers configuration
>
> this also makes initiatives like https://fedoraproject.org/wiki
> /Changes/CryptoPolicy useless and everything reacts faster than wait for
> the next PHP point release!
>
> I'm done with you. You don't understand and worse you don't want to
>> understand but think you understand. You just admitted to that. Please stop
>> until you get proper training as someone else on this list might make the
>> same mistakes that you are
>>
> yes, please stop to repsond to any of my mails, especially stop offlist
> mails
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


--
The greatest dangers to liberty lurk in insidious encroachment by men of
zeal, well-meaning but without understanding. -- Justice Louis D. Brandeis
Sorry, only registered users may post in this forum.

Click here to login