On Mon, May 29, 2017 at 7:59 PM, Anatol Belski <a...@php.net> wrote: > Hi, > > > I'd really prefer if this RFC targeted current patch branches. I > see > > minimal BC impact from the change (issues may only arise when > communicating > > with broken TLS implementations), while *not* making the change is > effectively > > a BC break as more servers stop supporting TLS 1.0. > > > > > For the lifetime of the 7.0 and 7.1 releases, it appears much more > likely > > to me that there will be more servers not supporting TLS 1.0 than servers > > supporting only TLS 1.0 *and* having a broken version negotiation > > implementation. > > > Nikita, IMHO there's too much uncertainty. It's not, that TLS 1.2 and co > is not supported at all. Basically, it is an app responsibility and issues > that which we should not try to fix. Real world is not going easy with the > changes of this kind. There are still and will be both that change rapidly > and those that stay longer. The linked doc from the original thread > https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls, > originally posted 2015, talks about "extending the migration completion > date to 30 June 2018 for transitioning from SSL and TLS 1.0 to a secure > version of TLS". Well, ... > > The issue I see to proceed this way into stable is, that the reliable > stats are missing and unlikely to get. The only info for now is the > original report, that *some* servers switched to TLS 1.2 only, and that > there are policy changes in payment card industry which recommends an > upgrade already for two years. From another point, I spoke to some > arbitrary companies and individuals I could reach, where the situation is > not different from "moving slow". Fe a company with up to 10-20 employs > still has to support old encryption protocols, because a switch would mean > they would have to throw away a half of their current hardware. It can ofc > go different depending on the industry branch, where to see is even sectors > like payment things go quite sluggish. Not telling it's a good situation, > but kinda usual. > > We didn't have a policy about default TLS versions till now, so a change > like that might be unexpected, depending on what OpenSSL wants to do under > the hood. Perhaps, regarding such a policy, we could say, that any PHP.next > whatsoever should support the latest available TLS version by default. An > app can always use an explicit TLS scheme if required, or it can upgrade > PHP. > > > > > Same here, but Anatol suggested releasing this with PHP 7.2 first and if > nobody > > complains, backport it to PHP 7.1 and 7.0. > > > Well, it was said before the patch was changed to touch ssl:// as well. In > the current approach, yes for 7.2 for sure. Otherwise, at least 7.0 is > already nearly half its lifetime old, so a controversial change like this > is probably too late without a good reason. > > I agree with Anatol. I don't think we should backport those changes. Especially for the tls:// changes that have a real BC (yes there are server that hang when 1.2 is negotiated and I have experienced it). That said I think it's good for 7.2!
Regards Jakub
