PHP 7.2.0 Released

  101207
November 30, 2017 10:59 remi@php.net (Remi Collet)
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
  101209
November 30, 2017 16:41 hannes.magnusson@gmail.com (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. Do you have a link to this commit ? -Hannes
  101210
November 30, 2017 17:07 remi@php.net (Remi Collet)
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
  101211
December 1, 2017 16:13 lists@rhsoft.net ("lists@rhsoft.net")
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
  101212
December 1, 2017 16:44 me@kelunik.com (Niklas Keller)
lists@rhsoft.net <lists@rhsoft.net> 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
>
  101213
December 1, 2017 16:52 lists@rhsoft.net ("lists@rhsoft.net")
Am 01.12.2017 um 17:44 schrieb Niklas Keller:
> lists@rhsoft.net <mailto:lists@rhsoft.net> <lists@rhsoft.net > <mailto:lists@rhsoft.net>> 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
  101214
December 1, 2017 21:49 pollita@php.net (Sara Golemon)
On Fri, Dec 1, 2017 at 11:52 AM, lists@rhsoft.net <lists@rhsoft.net> 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
  101215
December 1, 2017 23:35 lists@rhsoft.net ("lists@rhsoft.net")
Am 01.12.2017 um 22:49 schrieb Sara Golemon:
> On Fri, Dec 1, 2017 at 11:52 AM, lists@rhsoft.net <lists@rhsoft.net> 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
  101216
December 2, 2017 01:08 walterp@gmail.com (Walter Parker)
On Fri, Dec 1, 2017 at 3:35 PM, lists@rhsoft.net <lists@rhsoft.net> wrote:

> > > Am 01.12.2017 um 22:49 schrieb Sara Golemon: > >> On Fri, Dec 1, 2017 at 11:52 AM, lists@rhsoft.net <lists@rhsoft.net> >> 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
  101217
December 2, 2017 05:08 lists@rhsoft.net ("lists@rhsoft.net")
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
  101228
December 4, 2017 17:36 pollita@php.net (Sara Golemon)
On Fri, Dec 1, 2017 at 6:35 PM, lists@rhsoft.net <lists@rhsoft.net> 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
  101229
December 4, 2017 18:18 lists@rhsoft.net ("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 <lists@rhsoft.net> 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? [harry@srv-rhsoft:~]$ 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 ______________________ [harry@srv-rhsoft:~]$ 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)
  101230
December 4, 2017 18:36 lists@rhsoft.net ("lists@rhsoft.net")
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

[harry@srv-rhsoft:~]$ 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 <lists@rhsoft.net> >> 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? > > [harry@srv-rhsoft:~]$ 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 > ______________________ > > [harry@srv-rhsoft:~]$ 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) >
  101234
December 4, 2017 21:43 me@kelunik.com (Niklas Keller)
> > 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
  101235
December 4, 2017 21:53 walterp@gmail.com (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. > > 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
  101236
December 4, 2017 22:21 lists@rhsoft.net ("lists@rhsoft.net")
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-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
  101237
December 5, 2017 00:19 walterp@gmail.com (Walter Parker)
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
  101238
December 5, 2017 02:27 lists@rhsoft.net ("lists@rhsoft.net")
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 [harry@srv-rhsoft:~]$ 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
  101240
December 5, 2017 05:52 walterp@gmail.com (Walter Parker)
On Mon, Dec 4, 2017 at 6:27 PM, lists@rhsoft.net <lists@rhsoft.net> 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 > > [harry@srv-rhsoft:~]$ 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
  101241
December 5, 2017 08:54 lists@rhsoft.net ("lists@rhsoft.net")
Am 05.12.2017 um 06:52 schrieb Walter Parker:
> On Mon, Dec 4, 2017 at 6:27 PM, lists@rhsoft.net > <mailto:lists@rhsoft.net> <lists@rhsoft.net <mailto:lists@rhsoft.net>> > 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"
  101249
December 5, 2017 16:45 walterp@gmail.com (Walter Parker)
On Tue, Dec 5, 2017 at 12:54 AM, lists@rhsoft.net <lists@rhsoft.net> wrote:

> > > Am 05.12.2017 um 06:52 schrieb Walter Parker: > >> On Mon, Dec 4, 2017 at 6:27 PM, lists@rhsoft.net <mailto:lists@rhsoft.net> >> <lists@rhsoft.net <mailto:lists@rhsoft.net>> 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
  101250
December 5, 2017 17:09 lists@rhsoft.net ("lists@rhsoft.net")
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
  101251
December 5, 2017 17:34 walterp@gmail.com (Walter Parker)
Deleted without reading...

On Tue, Dec 5, 2017 at 9:09 AM, lists@rhsoft.net <lists@rhsoft.net> 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
  101231
December 4, 2017 19:52 pollita@php.net (Sara Golemon)
On Mon, Dec 4, 2017 at 1:18 PM, lists@rhsoft.net <lists@rhsoft.net> wrote:
> Am 04.12.2017 um 18:36 schrieb Sara Golemon: >> On Fri, Dec 1, 2017 at 6:35 PM, lists@rhsoft.net <lists@rhsoft.net> 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
  101233
December 4, 2017 21:36 bukka@php.net (Jakub Zelenka)
On Mon, Dec 4, 2017 at 5:36 PM, Sara Golemon <pollita@php.net> wrote:

> On Fri, Dec 1, 2017 at 6:35 PM, lists@rhsoft.net <lists@rhsoft.net> 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