> -----Original Message----- > From: li...@rhsoft.net [mailto:li...@rhsoft.net] > Sent: Thursday, May 11, 2017 2:27 PM > To: internals@lists.php.net > Subject: Re: [PHP-DEV] TLS v1.2 -only- deployments > > > > Am 11.05.2017 um 14:18 schrieb Anatol Belski: > > > > > >> -----Original Message----- > >> From: li...@rhsoft.net [mailto:li...@rhsoft.net] > >> Sent: Thursday, May 11, 2017 1:25 PM > >> To: internals@lists.php.net > >> Subject: Re: [PHP-DEV] TLS v1.2 -only- deployments > >> > >> > >> Am 11.05.2017 um 13:08 schrieb Anatol Belski: > >>>> -----Original Message----- > >>>> From: Thomas Hruska [mailto:thru...@cubiclesoft.com] > >>>> Sent: Tuesday, May 9, 2017 5:33 PM > >>>> To: PHP Development <internals@lists.php.net> > >>>> Subject: [PHP-DEV] TLS v1.2 -only- deployments > >>>> > >>>> Over the past two weeks, I've observed quite a bit of PHP 7+ > >>>> userland code breaking due to remote hosts switching to a TLS 1.2 only > policy. > >>>> For various specific reasons, I strongly suspect that PCI DSS 3.1 > >>>> implementations or compliance audits against that spec have > >>>> something to do with the changes that I'm seeing: > >>>> > >>>> https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early- > >>>> tl > >>>> s > >>>> > >>>> In just the last two weeks, I've seen completely unrelated servers > >>>> of various vendors go offline for an upgrade. When they come back > >>>> up a short bit later, they are suddenly configured for TLS 1.2 only. > >>>> Running a Qualys SSL labs test confirms the changes. It's a rather > >>>> specific change to encounter in such a short period of time. > >>>> > >>>> PHP userland code (e.g. stream_socket_client()) is unable to > >>>> connect to such hosts via "tls://" host strings. The string has to > >>>> be updated to use the version- specific string "tlsv1.2://" before > >>>> the connecting > >> code starts working again. > >>>> > >>> I think in any case, especially if apps are branch specific, > >>> explicit TSL 1.2 is probably the best way, like anything explicit in > >>> security > >> > >> yes but what *really* annoys me is that "tls://" don't just default > >> to the most secure connection *both* sides support > >> > > Yes, that's the current implementation. If there can be a better > implementation, perhaps it were worth it to pursue. > > shouldn't "tls://" just handover the handshake stuff to openssl? > If one can be sure OpenSSL does the expected thing, so why not? Or even doing it the way, that "tsl://" would start to try the best possible and retry with lower on fail, in which case PHP were in the exact control over what is going on. Either way, there seems still to be a time buffer for implementation and tests targeting 7.2, with the good feedback it could be even backported to lower branches.
> >> what do you do in a few years - change again userland php-code to > >> "tlsv1.3://" - franly that don't belong in any PHP script at all > >> because PHP is nothing else than i client here and a random developer > >> sould not need to know ahything about that low level things > >> > > For things like payments - certainly, the explicit highest security > > goes over any automatic negotiation. Standards don't change every day > > and a maintained app should follow the changes in the industry. Fe the > > particular doc there suggest an explicit migration path for the branch > > specific apps, explicitly mentioning to prefer TSL 1.2. On the other > > hand, for general purposes, one would want to keep the supported range > > as wide as possible > > it's fine that you can write "tlsv1.2://", "tlsv1.3://" explicit where it > makes sense > but you should not need to do so and just be able to say "tls://" and except > that > the underlying ssl library does the best possible handshake > > the current implementation makes "SSLHonorCipherOrder" and "SSLCipherSuite" > with a ordering to pass ssllabs on the serversie pointless when a stupid > client just > uses TLS1.0 > > maybe the underlying reason is the same that mysqli for encrypted database > connections is using "DHE-RSA-AES128-SHA" while /etc/my.cnf on the database > server has "ssl-cipher = ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128- > SHA256:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-GCM-SHA256:DHE-RSA- > AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:RSA-AES256-SHA" > From the github discussion, seems there was already some approach in 5.6, which was reverted because the real world struck back. AFM, still it looks like it'd make sense for stability to have some change in 7.2 in this direction, observer the pre phase and then decide a backport. Hopefully there'll be someone intrigued enough to go for an implementation. Regards Anatol
