# TLS v1.2 -only- deployments - Thread: https://externals.io/message/98987 - Original archive: https://news-web.php.net/php.internals/98987 - Started by Thomas Hruska on 2017-05-09T15:33:20+00:00 - Messages: 11 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #98987 — Thomas Hruska — 2017-05-09T15:33:20+00:00 URL: https://externals.io/message/98987#98987 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-tls 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. -- Thomas Hruska CubicleSoft President I've got great, time saving software that you will find useful. http://cubiclesoft.com/ --- ## #98995 — Niklas Keller — 2017-05-10T06:41:44+00:00 URL: https://externals.io/message/98987#98995 · In reply to: #98987 Hi Thomas, Thank you for that note. I've just filed a PR to change the default in PHP 7.2 and hope this may also make it into PHP 7.1 and 7.0. https://github.com/php/php-src/pull/2518 Regards, Niklas --- ## #99007 — Anatol Belski — 2017-05-11T11:08:45+00:00 URL: https://externals.io/message/98987#99007 · In reply to: #98987 Hi Thomas, > -----Original Message----- > From: Thomas Hruska [mailto:thruska@cubiclesoft.com] > Sent: Tuesday, May 9, 2017 5:33 PM > To: PHP Development > 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-tls > > 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. > What were interesting is to know some exact servers you mention to verify, if it were possible to call them by name. In general, probably having some reliable stats on the matter were not bad. Particularly with the reason you suspect - so if the changes are driven by the payment branch, they probably should be respected by both apps and servers. If some server providers do changes suddenly, thus breaching customer apps, we need to evaluate the extent of the breach. Fe stats linked by the Qualys labs itself tell there are still over 90% of of about 140 000 servers supporting TLS 1.0. OFC. Though, there are some billions of servers around the globe, so not sure how the stats are representative. 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. Regards Anatol --- ## #99009 — lists@rhsoft.net — 2017-05-11T11:24:32+00:00 URL: https://externals.io/message/98987#99009 · In reply to: #99007 Am 11.05.2017 um 13:08 schrieb Anatol Belski: > > […] > 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 yesm boiut what *really* annoys me is that "tls://" don't just default to the most secure connection *both* sides support 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 --- ## #99010 — Anatol Belski — 2017-05-11T12:18:53+00:00 URL: https://externals.io/message/98987#99010 · In reply to: #99009 > -----Original Message----- > From: lists@rhsoft.net [mailto:lists@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: > > […] > code starts working again. > > […] > > yesm boiut 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. > 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. Regards Anatol --- ## #99012 — lists@rhsoft.net — 2017-05-11T12:26:57+00:00 URL: https://externals.io/message/98987#99012 · In reply to: #99010 Am 11.05.2017 um 14:18 schrieb Anatol Belski: > > > > […] > 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? > > […] > 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" --- ## #99013 — Anatol Belski — 2017-05-11T12:58:33+00:00 URL: https://externals.io/message/98987#99013 · In reply to: #99012 > -----Original Message----- > From: lists@rhsoft.net [mailto:lists@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: > > […] > policy. > > […] > 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. > > […] > > 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 --- ## #99015 — Alice Wonder — 2017-05-11T14:05:26+00:00 URL: https://externals.io/message/98987#99015 · In reply to: #99007 > Hi Thomas, > > > […] > What were interesting is to know some exact servers you mention to verify, if it were possible to call them by name. In general, probably having some reliable stats on the matter were not bad. Particularly with the reason you suspect - so if the changes are driven by the payment branch, they probably should be respected by both apps and servers. If some server providers do changes suddenly, thus breaching customer apps, we need to evaluate the extent of the breach. Fe stats linked by the Qualys labs itself tell there are still over 90% of of about 140 000 servers supporting TLS 1.0. OFC. Though, there are some billions of servers around the globe, so not sure how the stats are representative. 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. > > Regards > > Anatol > I won't list them here because they are not the kind of sites appropriate for a list, but I am doing this with servers I admin. My current policy is that with every cert that expires (I generate new keys/certs yearly), when I bring the new cert into service, it is TLS 1.2 only. And with an extremely limited list of allowed ciphers. TLS 1.0 is old and at this point, the only browsers that do not support TLS 1.2 with the limited ciphers I allow are browsers that are no longer even getting security updates from their vendors. As such there is no point in continued support of them, and supporting deprecated clients is dangerous. --- ## #99016 — Alice Wonder — 2017-05-11T20:59:07+00:00 URL: https://externals.io/message/98987#99016 · In reply to: #99015 > > > […] > > I won't list them here because they are not the kind of sites > appropriate for a list, but I am doing this with servers I admin. > > My current policy is that with every cert that expires (I generate new > keys/certs yearly), when I bring the new cert into service, it is TLS > 1.2 only. And with an extremely limited list of allowed ciphers. > > TLS 1.0 is old and at this point, the only browsers that do not support > TLS 1.2 with the limited ciphers I allow are browsers that are no longer > even getting security updates from their vendors. > > As such there is no point in continued support of them, and supporting > deprecated clients is dangerous. > This one is safe for the list if people want to know what the TLS 1.2 only sites look like on ssllabs https://www.ssllabs.com/ssltest/analyze.html?d=deviant.email --- ## #99023 — Thomas Hruska — 2017-05-12T13:50:57+00:00 URL: https://externals.io/message/98987#99023 · In reply to: #99007 > Hi Thomas, > > > […] > What were interesting is to know some exact servers you mention to verify, if it were possible to call them by name. In general, probably having some reliable stats on the matter were not bad. Particularly with the reason you suspect - so if the changes are driven by the payment branch, they probably should be respected by both apps and servers. If some server providers do changes suddenly, thus breaching customer apps, we need to evaluate the extent of the breach. Fe stats linked by the Qualys labs itself tell there are still over 90% of of about 140 000 servers supporting TLS 1.0. OFC. Though, there are some billions of servers around the globe, so not sure how the stats are representative. 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. > > Regards > > Anatol Sorry for the delayed reply. For NDA reasons, I can't tell you which servers or vendors are involved. All I know is that I saw a bunch of systems across disparate vendors in a very short amount of time switching to TLS 1.2 only, which left me confused and wondering what in the world was going on. Only after someone in a completely unrelated context forwarded me a message they received from Authorize.net did I make a PCI DSS connection - all of the systems that changed are involved with PCI compliance and auditing to various degrees. Authorize.net recently publicly announced that they are migrating to TLS 1.2 only and have already switched their sandbox environment over: https://community.developer.authorize.net/t5/News-and-Announcements/Experiencing-Sandbox-Connection-Issues-TLS-1-2-Is-Now-Required/td-p/57948 -- Thomas Hruska CubicleSoft President I've got great, time saving software that you will find useful. http://cubiclesoft.com/ --- ## #99030 — Niklas Keller — 2017-05-14T07:46:52+00:00 URL: https://externals.io/message/98987#99030 · In reply to: #99023 > > For NDA reasons, I can't tell you which servers or vendors are involved. > All I know is that I saw a bunch of systems across disparate vendors in a > very short amount of time switching to TLS 1.2 only, which left me confused > and wondering what in the world was going on. Only after someone in a > completely unrelated context forwarded me a message they received from > Authorize.net did I make a PCI DSS connection - all of the systems that > changed are involved with PCI compliance and auditing to various degrees. > Authorize.net recently publicly announced that they are migrating to TLS > 1.2 only and have already switched their sandbox environment over: > > https://community.developer.authorize.net/t5/News-and-Announ > cements/Experiencing-Sandbox-Connection-Issues-TLS-1-2-Is- > Now-Required/td-p/57948 Yes, PayPal also announced these plans quite a while back. https://www.paypal.com/au/webapps/mpp/tls-http-upgrade I'll try to find the PHP 5.6 discussion later today. Regards, Niklas