Everything

php

TLS v1.2 -only- deployments

php.internals

Thomas Hruska

9 years ago

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/

Niklas Keller

9 years ago

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

Anatol Belski

9 years ago

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- 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

lists@rhsoft.net

9 years ago

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- 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.
>>
> 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

Anatol Belski

9 years ago

> -----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:
> >> -----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- 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
>
> 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

lists@rhsoft.net

9 years ago

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- deployments
>>
>>
>> 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- 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?

>> 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"

Anatol Belski

9 years ago

> -----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:
> >
> >
> >> -----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:
> >>>> -----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- 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

Alice Wonder

9 years ago

On 05/11/2017 04:08 AM, Anatol Belski wrote:

> 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- 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
>

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.

Alice Wonder

9 years ago

On 05/11/2017 07:05 AM, Alice Wonder wrote:

> On 05/11/2017 04:08 AM, Anatol Belski wrote:
>> 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- 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
>>
>
> 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

Thomas Hruska

9 years ago

On 5/11/2017 4:08 AM, Anatol Belski wrote:

> 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- 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

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/

Niklas Keller

9 years ago

>
> 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