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.
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
Hi Thomas,
-----Original Message-----
From: Thomas Hruska [mailto:thruska@cubiclesoft.com]
Sent: Tuesday, May 9, 2017 5:33 PM
To: PHP Development internals@lists.php.net
Subject: [PHP-DEV] TLS v1.2 -only- deploymentsOver 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
Am 11.05.2017 um 13:08 schrieb Anatol Belski:
-----Original Message-----
From: Thomas Hruska [mailto:thruska@cubiclesoft.com]
Sent: Tuesday, May 9, 2017 5:33 PM
To: PHP Development internals@lists.php.net
Subject: [PHP-DEV] TLS v1.2 -only- deploymentsOver 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.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
-----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- deploymentsAm 11.05.2017 um 13:08 schrieb Anatol Belski:
-----Original Message-----
From: Thomas Hruska [mailto:thruska@cubiclesoft.com]
Sent: Tuesday, May 9, 2017 5:33 PM
To: PHP Development internals@lists.php.net
Subject: [PHP-DEV] TLS v1.2 -only- deploymentsOver 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
sIn 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 securityyesm 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
Am 11.05.2017 um 14:18 schrieb Anatol Belski:
-----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- deploymentsAm 11.05.2017 um 13:08 schrieb Anatol Belski:
-----Original Message-----
From: Thomas Hruska [mailto:thruska@cubiclesoft.com]
Sent: Tuesday, May 9, 2017 5:33 PM
To: PHP Development internals@lists.php.net
Subject: [PHP-DEV] TLS v1.2 -only- deploymentsOver 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
sIn 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 securityyes but what really annoys me is that "tls://" don't just default to the most
secure connection both sides supportYes, 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?
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 thingsFor 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"
-----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- deploymentsAm 11.05.2017 um 14:18 schrieb Anatol Belski:
-----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- deploymentsAm 11.05.2017 um 13:08 schrieb Anatol Belski:
-----Original Message-----
From: Thomas Hruska [mailto:thruska@cubiclesoft.com]
Sent: Tuesday, May 9, 2017 5:33 PM
To: PHP Development internals@lists.php.net
Subject: [PHP-DEV] TLS v1.2 -only- deploymentsOver 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
sIn 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
securityyes but what really annoys me is that "tls://" don't just default
to the most secure connection both sides supportYes, 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 thingsFor 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 possibleit'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 handshakethe current implementation makes "SSLHonorCipherOrder" and "SSLCipherSuite"
with a ordering to pass ssllabs on the serversie pointless when a stupid client just
uses TLS1.0maybe 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
Hi Thomas,
-----Original Message-----
From: Thomas Hruska [mailto:thruska@cubiclesoft.com]
Sent: Tuesday, May 9, 2017 5:33 PM
To: PHP Development internals@lists.php.net
Subject: [PHP-DEV] TLS v1.2 -only- deploymentsOver 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
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.
Hi Thomas,
-----Original Message-----
From: Thomas Hruska [mailto:thruska@cubiclesoft.com]
Sent: Tuesday, May 9, 2017 5:33 PM
To: PHP Development internals@lists.php.net
Subject: [PHP-DEV] TLS v1.2 -only- deploymentsOver 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
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
Hi Thomas,
-----Original Message-----
From: Thomas Hruska [mailto:thruska@cubiclesoft.com]
Sent: Tuesday, May 9, 2017 5:33 PM
To: PHP Development internals@lists.php.net
Subject: [PHP-DEV] TLS v1.2 -only- deploymentsOver 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
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:
--
Thomas Hruska
CubicleSoft President
I've got great, time saving software that you will find useful.
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