Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99016
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain librelamp.com designates 45.79.96.192 as permitted sender)
To: internals@lists.php.net
References: <702de8c0-146e-268f-edf8-d0ea900a87e0@cubiclesoft.com>
 <VI1PR02MB1054AA17A954A35AE746B90ABAED0@VI1PR02MB1054.eurprd02.prod.outlook.com>
 <f4b7d4fc-906e-eeb9-b149-c8d5ac035b7f@librelamp.com>
Message-ID: <58d2c406-6d79-da73-d712-7b32ce2a1003@librelamp.com>
Date: Thu, 11 May 2017 13:59:07 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <f4b7d4fc-906e-eeb9-b149-c8d5ac035b7f@librelamp.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] TLS v1.2 -only- deployments
From: alice@librelamp.com (Alice Wonder)

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