[RFC][VOTE] Improved SSL / TLS constants

8 years ago by Niklas Keller — view source

unread

Morning,

I hereby open the vote on the "Improved SSL / TLS constants" RFC.

This RFC proposes to change PHP's TLS constants to sane values. This change
has been avoided by the previous RFC for PHP 5.6 due to BC reasons. This
RFCs favors better security instead of backwards compatibility with version
intolerant and out of date servers.

You can find the full RFC here:
https://wiki.php.net/rfc/improved-tls-constants

Regards, Niklas

8 years ago by lists@rhsoft.net — view source

unread

Am 29.05.2017 um 09:48 schrieb Niklas Keller:

Morning,

I hereby open the vote on the "Improved SSL / TLS constants" RFC.

This RFC proposes to change PHP's TLS constants to sane values. This change
has been avoided by the previous RFC for PHP 5.6 due to BC reasons. This
RFCs favors better security instead of backwards compatibility with version
intolerant and out of date servers.

You can find the full RFC here:
https://wiki.php.net/rfc/improved-tls-constants

Make tls:// default to TLSv1.0 + TLSv1.1 + TLSv1.2

this is nice for a limited timeframe but the wrong approach to begin
with - it is not the business of PHP at all until explicit requested
from the uselrand code to interfer with anything in context of the TLS
handshake

it's the job of the underlying openssl library, how it is built and
shipped by the distribution becaus ethey you support implicit TLS1.3 and
a future TLS1.4, don't weaken things like
https://fedoraproject.org/wiki/Changes/CryptoPolicy and respect san
econfigured servers which are regulary checked with
https://www.ssllabs.com/ssltest/

8 years ago by Niklas Keller — view source

unread

2017-05-29 10:18 GMT+02:00 lists@rhsoft.net lists@rhsoft.net:

Am 29.05.2017 um 09:48 schrieb Niklas Keller:

Morning,

I hereby open the vote on the "Improved SSL / TLS constants" RFC.

This RFC proposes to change PHP's TLS constants to sane values. This
change
has been avoided by the previous RFC for PHP 5.6 due to BC reasons. This
RFCs favors better security instead of backwards compatibility with
version
intolerant and out of date servers.

You can find the full RFC here:
https://wiki.php.net/rfc/improved-tls-constants

Make tls:// default to TLSv1.0 + TLSv1.1 + TLSv1.2

this is nice for a limited timeframe but the wrong approach to begin with

it is not the business of PHP at all until explicit requested from
the uselrand code to interfer with anything in context of the TLS
handshake

it's the job of the underlying openssl library, how it is built and
shipped by the distribution becaus ethey you support implicit TLS1.3 and a
future TLS1.4, don't weaken things like https://fedoraproject.org/wiki
/Changes/CryptoPolicy and respect san econfigured servers which are
regulary checked with https://www.ssllabs.com/ssltest/

Unfortunately, the underlying OpenSSL library fails providing sane defaults.

There are plans to switch to another mechanism supporting a min_version
and max_version instead, but this is not a thing yet.

Regards, Niklas

8 years ago by Jakub Zelenka — view source

unread

Am 29.05.2017 um 09:48 schrieb Niklas Keller:

Morning,

I hereby open the vote on the "Improved SSL / TLS constants" RFC.

This RFC proposes to change PHP's TLS constants to sane values. This
change
has been avoided by the previous RFC for PHP 5.6 due to BC reasons. This
RFCs favors better security instead of backwards compatibility with
version
intolerant and out of date servers.

You can find the full RFC here:
https://wiki.php.net/rfc/improved-tls-constants

Make tls:// default to TLSv1.0 + TLSv1.1 + TLSv1.2

this is nice for a limited timeframe but the wrong approach to begin with

it is not the business of PHP at all until explicit requested from
the uselrand code to interfer with anything in context of the TLS
handshake

it's the job of the underlying openssl library, how it is built and
shipped by the distribution becaus ethey you support implicit TLS1.3 and a
future TLS1.4, don't weaken things like https://fedoraproject.org/wiki
/Changes/CryptoPolicy and respect san econfigured servers which are
regulary checked with https://www.ssllabs.com/ssltest/

Once the TLS 1.3 support is added, it will be in it as well. I think we
should stay away from setting specific protocols and go just for min and
max which is the way that OpenSSL is going though.

Cheers

Jakub

8 years ago by Nikita Popov — view source

unread

Morning,

I hereby open the vote on the "Improved SSL / TLS constants" RFC.

This RFC proposes to change PHP's TLS constants to sane values. This change
has been avoided by the previous RFC for PHP 5.6 due to BC reasons. This
RFCs favors better security instead of backwards compatibility with version
intolerant and out of date servers.

You can find the full RFC here:
https://wiki.php.net/rfc/improved-tls-constants

Regards, Niklas

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

8 years ago by Niklas Keller — view source

unread

2017-05-29 12:56 GMT+02:00 Nikita Popov nikita.ppv@gmail.com:

Morning,

I hereby open the vote on the "Improved SSL / TLS constants" RFC.

This RFC proposes to change PHP's TLS constants to sane values. This
change
has been avoided by the previous RFC for PHP 5.6 due to BC reasons. This
RFCs favors better security instead of backwards compatibility with
version
intolerant and out of date servers.

You can find the full RFC here:
https://wiki.php.net/rfc/improved-tls-constants

Regards, Niklas

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.

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.

Regards, Niklas

8 years ago by Anatol Belski — view source

unread

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.

Niklas, I'd have yet a question about the RFC - it only deals with stream wrappers, but there are indeed some other places at least in soap and mysqlnd. Don't you think, the RFC and implementation should recapitulate those?

Regards

Anatol

8 years ago by Jakub Zelenka — view source

unread

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

8 years ago by Niklas Keller — view source

unread

Hey Anatol,

Niklas, I'd have yet a question about the RFC - it only deals with stream
wrappers, but there are indeed some other places at least in soap and
mysqlnd. Don't you think, the RFC and implementation should recapitulate
those?

Do you have a link to those places?

Regards, Niklas

8 years ago by Anatol Belski — view source

unread

Hi Niklas,

-----Original Message-----
From: Niklas Keller [mailto:me@kelunik.com]
Sent: Monday, May 29, 2017 10:14 PM
To: Anatol Belski ab@php.net
Cc: Nikita Popov nikita.ppv@gmail.com; PHP Internals
internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC][VOTE] Improved SSL / TLS constants

Hey Anatol,

Niklas, I'd have yet a question about the RFC - it only deals with stream
wrappers, but there are indeed some other places at least in soap and mysqlnd.
Don't you think, the RFC and implementation should recapitulate those?

Yep, here you are

https://github.com/php/php-src/blob/master/ext/soap/php_http.c#L305
https://github.com/php/php-src/blob/master/ext/mysqlnd/mysqlnd_net.c#L974

Basically it is the same story, as the old definitions are used, which the RFC aims to replace. It might be consistent to have the behavior synced, or at least to evaluate it. And, there might yet some places, not expecting much but just to be aware.

Regards

Anatol

8 years ago by Niklas Keller — view source

unread

2017-05-29 22:29 GMT+02:00 Anatol Belski ab@php.net:

Hi Niklas,
-----Original Message-----
From: Niklas Keller [mailto:me@kelunik.com]
Sent: Monday, May 29, 2017 10:14 PM
To: Anatol Belski ab@php.net
Cc: Nikita Popov nikita.ppv@gmail.com; PHP Internals
internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC][VOTE] Improved SSL / TLS constants

Hey Anatol,
  Niklas, I'd have yet a question about the RFC - it only deals with
stream

wrappers, but there are indeed some other places at least in soap and
mysqlnd.
Don't you think, the RFC and implementation should recapitulate those?

Yep, here you are

https://github.com/php/php-src/blob/master/ext/soap/php_http.c#L305
https://github.com/php/php-src/blob/master/ext/mysqlnd/mysqlnd_net.c#L974

Basically it is the same story, as the old definitions are used, which the
RFC aims to replace. It might be consistent to have the behavior synced, or
at least to evaluate it. And, there might yet some places, not expecting
much but just to be aware.

Regards

Hi Anatol,

I upgraded STREAM_CRYPTO_METHOD_TLS_CLIENT to be an alias
to STREAM_CRYPTO_METHOD_TLS_ANY_CLIENT now, so that automatically upgrades
any use of STREAM_CRYPTO_METHOD_TLS_CLIENT to use TLS 1.1 or TLS 1.2 if
available.

Regards, Niklas

8 years ago by Niklas Keller — view source

unread

2017-06-04 11:22 GMT+02:00 Niklas Keller me@kelunik.com:

2017-05-29 22:29 GMT+02:00 Anatol Belski ab@php.net:
Hi Niklas,
-----Original Message-----
From: Niklas Keller [mailto:me@kelunik.com]
Sent: Monday, May 29, 2017 10:14 PM
To: Anatol Belski ab@php.net
Cc: Nikita Popov nikita.ppv@gmail.com; PHP Internals
internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC][VOTE] Improved SSL / TLS constants

Hey Anatol,
  Niklas, I'd have yet a question about the RFC - it only deals
with stream

wrappers, but there are indeed some other places at least in soap and
mysqlnd.
Don't you think, the RFC and implementation should recapitulate those?

Yep, here you are

https://github.com/php/php-src/blob/master/ext/soap/php_http.c#L305
https://github.com/php/php-src/blob/master/ext/mysqlnd/mysqlnd_net.c#L974

Basically it is the same story, as the old definitions are used, which
the RFC aims to replace. It might be consistent to have the behavior
synced, or at least to evaluate it. And, there might yet some places, not
expecting much but just to be aware.

Regards
Hi Anatol,

I upgraded STREAM_CRYPTO_METHOD_TLS_CLIENT to be an alias
to STREAM_CRYPTO_METHOD_TLS_ANY_CLIENT now, so that automatically
upgrades any use of STREAM_CRYPTO_METHOD_TLS_CLIENT to use TLS 1.1 or TLS
1.2 if available.

Regards, Niklas

Hey everyone,

thanks for voting! The voting has now been closed with 14 votes in favor
and 0 against.

You can see the full results on the voting page as always:
https://wiki.php.net/rfc/improved-tls-constants#voting

Regards, Niklas