Welcome! Log In Create A New Profile

Advanced

[PHP-DEV] [RFC] Distrust SHA-1 Certificates

Posted by Niklas Keller 
Niklas Keller
[PHP-DEV] [RFC] Distrust SHA-1 Certificates
December 13, 2016 05:51AM
Morning Internals,

I plan to distrust SHA-1 certificates by default in PHP 7.2. All major
browsers will no longer trust SHA-1 certificates starting already
2017-01-01.

Unfortunately, PHP doesn't even provide a way yet to limit the accepted
algorithms for certificates. The RFC fixes that and introduces new defaults
for PHP 7.2. The "signature_algorithms" context option will also be
backported to PHP 5.6, which is only supported until the end of 2016 with
regular releases, but after that there will be two more years of
security-only updates. Therefore I'd like to get this done before the end
of 2016.

Currently the RFC aims for BC and doesn't restrict the algorithms on older
versions. As all major browsers start distrusting those certificates on
2017-01-01 I'm not sure whether that's the correct choice. I'd like to go
secure-by-default there and disable SHA-1 also on older versions. People
which really need longer can always opt-out and add the needed algorithms
again. Unfortunately, we didn't announce any plans regarding SHA-1 yet, so
this might be a bit last-minute.

You can read the full RFC in the wiki:
https://wiki.php.net/rfc/distrust-sha1-certificates

Regards, Niklas
Stanislav Malyshev
Re: [PHP-DEV] [RFC] Distrust SHA-1 Certificates
December 13, 2016 05:51AM
Hi!

> You can read the full RFC in the wiki:
> https://wiki.php.net/rfc/distrust-sha1-certificates

I would propose making a constant for default value. This way if your
code wants to use that option is a generic way, there is a value to fall
back on, and you don't need to keep around a long string that can be
mis-copied, etc.

--
Stas Malyshev
smalyshev@gmail.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Niklas Keller
Re: [PHP-DEV] [RFC] Distrust SHA-1 Certificates
December 13, 2016 05:51AM
>
> I would propose making a constant for default value. This way if your
> code wants to use that option is a generic way, there is a value to fall
> back on, and you don't need to keep around a long string that can be
> mis-copied, etc.
>

A constant for the default value doesn't make much sense to me, as you
shouldn't set the default value, it's already the default. If we want
constants, we could have one for SHA-1 and another for the SHA-2 group.

We already have http://php.net/manual/en/openssl.signature-algos.php, but
those are integers unfortunately.

Regards, Niklas
Jakub Zelenka
Re: [PHP-DEV] [RFC] Distrust SHA-1 Certificates
December 13, 2016 05:51AM
On Sat, Nov 26, 2016 at 3:49 PM, Niklas Keller <me@kelunik.com> wrote:

> Morning Internals,
>
> I plan to distrust SHA-1 certificates by default in PHP 7.2. All major
> browsers will no longer trust SHA-1 certificates starting already
> 2017-01-01.
>
> Unfortunately, PHP doesn't even provide a way yet to limit the accepted
> algorithms for certificates. The RFC fixes that and introduces new defaults
> for PHP 7.2. The "signature_algorithms" context option will also be
> backported to PHP 5.6, which is only supported until the end of 2016 with
> regular releases, but after that there will be two more years of
> security-only updates. Therefore I'd like to get this done before the end
> of 2016.
>
> Currently the RFC aims for BC and doesn't restrict the algorithms on older
> versions. As all major browsers start distrusting those certificates on
> 2017-01-01 I'm not sure whether that's the correct choice. I'd like to go
> secure-by-default there and disable SHA-1 also on older versions. People
> which really need longer can always opt-out and add the needed algorithms
> again. Unfortunately, we didn't announce any plans regarding SHA-1 yet, so
> this might be a bit last-minute.
>
> You can read the full RFC in the wiki:
> https://wiki.php.net/rfc/distrust-sha1-certificates
>
>
I think you should change the format to match the one supported by OpenSSL
[1] which is also simpler.

In general I'm not a big fan of such defaults especially when new values
can be added later (e.g. EdDSA that is specified in TLS 1.3) so we have to
keep it up to date which was kind of issue in the past. However I see the
point that we should make it easier for users to have it secure by default
so it's probably a good choice. It's not actually just about SHA

I'm not so sure about 5.6 as we are very close to the end of active support
and if this introduces any bug, we won't be able to fix it. It would be
also motivation for some users to update to 7.

[1] https://www.openssl.org/docs/man1.1.0/ssl/SSL_CTX_set1_sigalgs_list.html
[2]

Cheers

Jakub
Jakub Zelenka
Re: [PHP-DEV] [RFC] Distrust SHA-1 Certificates
December 13, 2016 05:51AM
On Sun, Nov 27, 2016 at 1:06 PM, Jakub Zelenka <bukka@php.net> wrote:

>
>
> On Sat, Nov 26, 2016 at 3:49 PM, Niklas Keller <me@kelunik.com> wrote:
>
>> Morning Internals,
>>
>> I plan to distrust SHA-1 certificates by default in PHP 7.2. All major
>> browsers will no longer trust SHA-1 certificates starting already
>> 2017-01-01.
>>
>> Unfortunately, PHP doesn't even provide a way yet to limit the accepted
>> algorithms for certificates. The RFC fixes that and introduces new
>> defaults
>> for PHP 7.2. The "signature_algorithms" context option will also be
>> backported to PHP 5.6, which is only supported until the end of 2016 with
>> regular releases, but after that there will be two more years of
>> security-only updates. Therefore I'd like to get this done before the end
>> of 2016.
>>
>> Currently the RFC aims for BC and doesn't restrict the algorithms on older
>> versions. As all major browsers start distrusting those certificates on
>> 2017-01-01 I'm not sure whether that's the correct choice. I'd like to go
>> secure-by-default there and disable SHA-1 also on older versions. People
>> which really need longer can always opt-out and add the needed algorithms
>> again. Unfortunately, we didn't announce any plans regarding SHA-1 yet, so
>> this might be a bit last-minute.
>>
>> You can read the full RFC in the wiki:
>> https://wiki.php.net/rfc/distrust-sha1-certificates
>>
>>
> I think you should change the format to match the one supported by OpenSSL
> [1] which is also simpler.
>
> In general I'm not a big fan of such defaults especially when new values
> can be added later (e.g. EdDSA that is specified in TLS 1.3) so we have to
> keep it up to date which was kind of issue in the past. However I see the
> point that we should make it easier for users to have it secure by default
> so it's probably a good choice. It's not actually just about SHA
>
>

Ah sent before I finished it. :) I wanted to say that it's not just about
SHA-1 but also MD5 that I think we might still support but would have to
double check that...
Niklas Keller
Re: [PHP-DEV] [RFC] Distrust SHA-1 Certificates
December 13, 2016 05:51AM
2016-11-27 14:09 GMT+01:00 Jakub Zelenka <bukka@php.net>:

>
>
> On Sun, Nov 27, 2016 at 1:06 PM, Jakub Zelenka <bukka@php.net> wrote:
>
>>
>>
>> On Sat, Nov 26, 2016 at 3:49 PM, Niklas Keller <me@kelunik.com> wrote:
>>
>>> Morning Internals,
>>>
>>> I plan to distrust SHA-1 certificates by default in PHP 7.2. All major
>>> browsers will no longer trust SHA-1 certificates starting already
>>> 2017-01-01.
>>>
>>> Unfortunately, PHP doesn't even provide a way yet to limit the accepted
>>> algorithms for certificates. The RFC fixes that and introduces new
>>> defaults
>>> for PHP 7.2. The "signature_algorithms" context option will also be
>>> backported to PHP 5.6, which is only supported until the end of 2016 with
>>> regular releases, but after that there will be two more years of
>>> security-only updates. Therefore I'd like to get this done before the end
>>> of 2016.
>>>
>>> Currently the RFC aims for BC and doesn't restrict the algorithms on
>>> older
>>> versions. As all major browsers start distrusting those certificates on
>>> 2017-01-01 I'm not sure whether that's the correct choice. I'd like to go
>>> secure-by-default there and disable SHA-1 also on older versions. People
>>> which really need longer can always opt-out and add the needed algorithms
>>> again. Unfortunately, we didn't announce any plans regarding SHA-1 yet,
>>> so
>>> this might be a bit last-minute.
>>>
>>> You can read the full RFC in the wiki:
>>> https://wiki.php.net/rfc/distrust-sha1-certificates
>>>
>>>
>> I think you should change the format to match the one supported by
>> OpenSSL [1] which is also simpler.
>>
>
It is exactly in OpenSSL's format for SSL_CTX_set1_sigalgs_list.


> In general I'm not a big fan of such defaults especially when new values
>> can be added later (e.g. EdDSA that is specified in TLS 1.3) so we have to
>> keep it up to date which was kind of issue in the past.
>>
>
That's true, but I don't see a way in OpenSSL do have a blacklist instead,
but we could do that in our own verify callback.


> However I see the point that we should make it easier for users to have it
>> secure by default so it's probably a good choice. It's not actually just
>> about SHA
>>
>
> Ah sent before I finished it. :) I wanted to say that it's not just about
> SHA-1 but also MD5 that I think we might still support but would have to
> double check that...
>

I wanted to double-check that, too, but didn't do that yet. If MD5 is still
supported, we should definitely put it into PHP 5.6 as a security update.

As far as I can see, MD5 support is the case if it has not been disabled by
the OpenSSL version in use, as all supported algorithms are allowed by
default.

SSL_CTX_set1_sigalgs is anyway only supported starting in OpenSSL 1.0.2, so
we need a custom verify callback for older OpenSSL versions. In our own
verify callback we can use a blacklist instead of the suggested whitelist
by default.

Regards, Niklas
Jakub Zelenka
Re: [PHP-DEV] [RFC] Distrust SHA-1 Certificates
December 13, 2016 05:51AM
On Sun, Nov 27, 2016 at 2:22 PM, Niklas Keller <me@kelunik.com> wrote:

>
>
> 2016-11-27 14:09 GMT+01:00 Jakub Zelenka <bukka@php.net>:
>
>>
>>
>> On Sun, Nov 27, 2016 at 1:06 PM, Jakub Zelenka <bukka@php.net> wrote:
>>
>>>
>>>
>>> On Sat, Nov 26, 2016 at 3:49 PM, Niklas Keller <me@kelunik.com> wrote:
>>>
>>>> Morning Internals,
>>>>
>>>> I plan to distrust SHA-1 certificates by default in PHP 7.2. All major
>>>> browsers will no longer trust SHA-1 certificates starting already
>>>> 2017-01-01.
>>>>
>>>> Unfortunately, PHP doesn't even provide a way yet to limit the accepted
>>>> algorithms for certificates. The RFC fixes that and introduces new
>>>> defaults
>>>> for PHP 7.2. The "signature_algorithms" context option will also be
>>>> backported to PHP 5.6, which is only supported until the end of 2016
>>>> with
>>>> regular releases, but after that there will be two more years of
>>>> security-only updates. Therefore I'd like to get this done before the
>>>> end
>>>> of 2016.
>>>>
>>>> Currently the RFC aims for BC and doesn't restrict the algorithms on
>>>> older
>>>> versions. As all major browsers start distrusting those certificates on
>>>> 2017-01-01 I'm not sure whether that's the correct choice. I'd like to
>>>> go
>>>> secure-by-default there and disable SHA-1 also on older versions. People
>>>> which really need longer can always opt-out and add the needed
>>>> algorithms
>>>> again. Unfortunately, we didn't announce any plans regarding SHA-1 yet,
>>>> so
>>>> this might be a bit last-minute.
>>>>
>>>> You can read the full RFC in the wiki:
>>>> https://wiki.php.net/rfc/distrust-sha1-certificates
>>>>
>>>>
>>> I think you should change the format to match the one supported by
>>> OpenSSL [1] which is also simpler.
>>>
>>
> It is exactly in OpenSSL's format for SSL_CTX_set1_sigalgs_list.
>

Ah you right. I incorrectly read the RFC. So it's fine then.


>
>
>> In general I'm not a big fan of such defaults especially when new values
>>> can be added later (e.g. EdDSA that is specified in TLS 1.3) so we have to
>>> keep it up to date which was kind of issue in the past.
>>>
>>
> That's true, but I don't see a way in OpenSSL do have a blacklist instead,
> but we could do that in our own verify callback.
>

Yeah but not sure if it's ideal too. Will have to think about it.


>
>
>> However I see the point that we should make it easier for users to have
>>> it secure by default so it's probably a good choice. It's not actually just
>>> about SHA
>>>
>>
>> Ah sent before I finished it. :) I wanted to say that it's not just about
>> SHA-1 but also MD5 that I think we might still support but would have to
>> double check that...
>>
>
> I wanted to double-check that, too, but didn't do that yet. If MD5 is
> still supported, we should definitely put it into PHP 5.6 as a security
> update.
>
> As far as I can see, MD5 support is the case if it has not been disabled
> by the OpenSSL version in use, as all supported algorithms are allowed by
> default.
>
> SSL_CTX_set1_sigalgs is anyway only supported starting in OpenSSL 1.0.2,
> so we need a custom verify callback for older OpenSSL versions. In our own
> verify callback we can use a blacklist instead of the suggested whitelist
> by default.
>
>
No need to add support for 1.0.1 as it's going to be EOL end of December.
Lower version are EOL already.

Cheers

Jakub
Niklas Keller
Re: [PHP-DEV] [RFC] Distrust SHA-1 Certificates
December 13, 2016 05:51AM
>
> > SSL_CTX_set1_sigalgs is anyway only supported starting in OpenSSL 1.0.2,
> > so we need a custom verify callback for older OpenSSL versions. In our
> own
> > verify callback we can use a blacklist instead of the suggested whitelist
> > by default.
> >
> >
> No need to add support for 1.0.1 as it's going to be EOL end of December.
> Lower version are EOL already.
>

That may be true, but we only raised the minimum requirement for newer
versions of PHP. If this is going to be backported for PHP 5.6 / 7.0 / 7.1,
we have to support those older OpenSSL versions I guess?

Regards, Niklas
Jakub Zelenka
Re: [PHP-DEV] [RFC] Distrust SHA-1 Certificates
December 13, 2016 05:51AM
On Sun, Nov 27, 2016 at 3:17 PM, Niklas Keller <me@kelunik.com> wrote:

> > SSL_CTX_set1_sigalgs is anyway only supported starting in OpenSSL 1.0.2,
>> > so we need a custom verify callback for older OpenSSL versions. In our
>> own
>> > verify callback we can use a blacklist instead of the suggested
>> whitelist
>> > by default.
>> >
>> >
>> No need to add support for 1.0.1 as it's going to be EOL end of December.
>> Lower version are EOL already.
>>
>
> That may be true, but we only raised the minimum requirement for newer
> versions of PHP. If this is going to be backported for PHP 5.6 / 7.0 / 7.1,
> we have to support those older OpenSSL versions I guess?
>
>
Well it depends if it requires feature available only in the later version
of OpenSSL which would be the case for the currently proposed version of
the RFC that would make use of SSL_CTX_set1_sigalgs_list macro. I don't
think that we should parse the string of allowed sig algs and re-implement
it for OpenSSL versions that are EOL anyway. It's not something unusual to
have a feature dependent on the library version. For example we did exactly
the some for openssl_pbkdf2 that worked only if it was compiled with
OpenSSL 1.0.0+. So if you had PHP 7.0 and OpenSSL 0.9.8, it wasn't
available.

I have been thinking about the defaults and I don't think we should have
any default value for this. Instead we should concentrate on supporting
security levels [1]. That will give a much better way how to define a
number of bits security. For example if we have selected level 2 to get 112
bits of security, then the SSH-1 sig algs would be automatically disabled
as it offers only 80 bits of security. It would also disable all other
weaker algs so user couldn't for example use RSA keys shorter than 2048
bits. That's much better and easier way for users to define the security as
they would just need to set a number (from 0 to 5 atm). I'm aware that
this is supported only by OpenSSL 1.1 but I wouldn't see that as an issue.
At the time the PHP 7.2 is out, there will be much bigger usage of OpenSSL
1.1 and the users on lower version could still disable it manually.

[1]
https://www.openssl.org/docs/man1.1.0/ssl/SSL_CTX_set_security_level.html

Cheers

Jakub
Niklas Keller
Re: [PHP-DEV] [RFC] Distrust SHA-1 Certificates
December 13, 2016 05:51AM
>
> Well it depends if it requires feature available only in the later version
>> of OpenSSL which would be the case for the currently proposed version of
>> the RFC that would make use of SSL_CTX_set1_sigalgs_list macro. I don't
>> think that we should parse the string of allowed sig algs and re-implement
>> it for OpenSSL versions that are EOL anyway. It's not something unusual to
>> have a feature dependent on the library version. For example we did exactly
>> the some for openssl_pbkdf2 that worked only if it was compiled with
>> OpenSSL 1.0.0+. So if you had PHP 7.0 and OpenSSL 0.9.8, it wasn't
>> available.
>>
>
Having a feature not available is different from having a security issue if
you're using the wrong OpenSSL version.


> I have been thinking about the defaults and I don't think we should have
> any default value for this. Instead we should concentrate on supporting
> security levels [1]. That will give a much better way how to define a
> number of bits security. For example if we have selected level 2 to get 112
> bits of security, then the SSH-1 sig algs would be automatically disabled
> as it offers only 80 bits of security. It would also disable all other
> weaker algs so user couldn't for example use RSA keys shorter than 2048
> bits. That's much better and easier way for users to define the security as
> they would just need to set a number (from 0 to 5 atm). I'm aware that
> this is supported only by OpenSSL 1.1 but I wouldn't see that as an issue.
> At the time the PHP 7.2 is out, there will be much bigger usage of OpenSSL
> 1.1 and the users on lower version could still disable it manually.
>

I've seen that, too. I've been confused by SHA-1 being mentioned at level
4, but I missed that it's only talking about the MAC mechanism there.

I guess this is the better alternative, but in any way, we have to fix 5.6+
to remove MD5 support I think.

Regards, Niklas


> [1] https://www.openssl.org/docs/man1.1.0/ssl/SSL_CTX_set_
> security_level.html
>
> Cheers
>
> Jakub
>
Jan Ehrhardt
Re: [PHP-DEV] [RFC] Distrust SHA-1 Certificates
December 13, 2016 05:51AM
Jakub Zelenka in php.internals (Sun, 27 Nov 2016 19:37:50 +0000):
>On Sun, Nov 27, 2016 at 3:17 PM, Niklas Keller <me@kelunik.com> wrote:
>> That may be true, but we only raised the minimum requirement for newer
>> versions of PHP. If this is going to be backported for PHP 5.6 / 7.0 / 7.1,
>> we have to support those older OpenSSL versions I guess?
>>
>>
>Well it depends if it requires feature available only in the later version
>of OpenSSL which would be the case for the currently proposed version of
>the RFC that would make use of SSL_CTX_set1_sigalgs_list macro. I don't
>think that we should parse the string of allowed sig algs and re-implement
>it for OpenSSL versions that are EOL anyway. It's not something unusual to
>have a feature dependent on the library version. For example we did exactly
>the some for openssl_pbkdf2 that worked only if it was compiled with
>OpenSSL 1.0.0+. So if you had PHP 7.0 and OpenSSL 0.9.8, it wasn't
>available.

As a side note: I haven't yet met an extension that does not compile
with OpenSSL 1.0.2. For a long time now, all my PHP 5.3, 5.4, 5.5 and
5.6 (Windows) builds are compiled with OpenSSL 1.0.2.
--
Jan

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Jan Ehrhardt
Re: [PHP-DEV] [RFC] Distrust SHA-1 Certificates
December 13, 2016 05:51AM
Jakub Zelenka in php.internals (Sun, 27 Nov 2016 19:37:50 +0000):
>At the time the PHP 7.2 is out, there will be much bigger usage of OpenSSL
>1.1 and the users on lower version could still disable it manually.

I sure hope so. What concerns me is that there is no movement at all to
add OpenSSL 1.1 support to Apache. It could take longer than you think
for a broad support of OpenSSL 1.1.
--
Jan

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Niklas Keller
[PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
May 29, 2017 01:00PM
Morning Internals,

I have updated the RFC to use a "min_signature_bits" setting instead.

Please share your thoughts.

https://wiki.php.net/rfc/distrust-sha1-certificates

Regards, Niklas

2016-11-26 16:49 GMT+01:00 Niklas Keller <me@kelunik.com>:

> Morning Internals,
>
> I plan to distrust SHA-1 certificates by default in PHP 7.2. All major
> browsers will no longer trust SHA-1 certificates starting already
> 2017-01-01.
>
> Unfortunately, PHP doesn't even provide a way yet to limit the accepted
> algorithms for certificates. The RFC fixes that and introduces new defaults
> for PHP 7.2. The "signature_algorithms" context option will also be
> backported to PHP 5.6, which is only supported until the end of 2016 with
> regular releases, but after that there will be two more years of
> security-only updates. Therefore I'd like to get this done before the end
> of 2016.
>
> Currently the RFC aims for BC and doesn't restrict the algorithms on older
> versions. As all major browsers start distrusting those certificates on
> 2017-01-01 I'm not sure whether that's the correct choice. I'd like to go
> secure-by-default there and disable SHA-1 also on older versions. People
> which really need longer can always opt-out and add the needed algorithms
> again. Unfortunately, we didn't announce any plans regarding SHA-1 yet, so
> this might be a bit last-minute.
>
> You can read the full RFC in the wiki: https://wiki.php.net/
> rfc/distrust-sha1-certificates
>
> Regards, Niklas
>
Lauri Kenttä
Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
May 29, 2017 04:10PM
On 2017-05-29 13:58, Niklas Keller wrote:
> I have updated the RFC to use a "min_signature_bits" setting instead.

At least that name is misleading. Most PHP users would probably wonder
why a setting of 128 does not allow the 160-bit hash from SHA-1 or the
512-bit RSA. So the name should be more like
"min_cryptographic_strength" (possibly prefixed with "signature_") to
make it clear that this is not really about the bits in signature.

I'm not totally convinced about this bit approach in general. What
happens if SHA-2 is suddenly broken and people move to SHA-3 of the same
length?

Just my thoughts.

--
Lauri Kenttä

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Jakub Zelenka
[PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
May 29, 2017 10:10PM
On Mon, May 29, 2017 at 11:58 AM, Niklas Keller <me@kelunik.com> wrote:

> Morning Internals,
>
> I have updated the RFC to use a "min_signature_bits" setting instead.
>
>
Wouldn't be better use security levels instead as it is in OpenSSL? Of
course I mean just for sig level to not re-implement everything. Basically
having sig_level or something like that...
Niklas Keller
[PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
May 29, 2017 10:20PM
2017-05-29 22:00 GMT+02:00 Jakub Zelenka <bukka@php.net>:

> On Mon, May 29, 2017 at 11:58 AM, Niklas Keller <me@kelunik.com> wrote:
>
>> Morning Internals,
>>
>> I have updated the RFC to use a "min_signature_bits" setting instead.
>>
>>
> Wouldn't be better use security levels instead as it is in OpenSSL? Of
> course I mean just for sig level to not re-implement everything. Basically
> having sig_level or something like that...
>

As we can't use the OpenSSL implementation directly, I don't see any reason
to use arbitrary integers there which you have to look up again. Maybe we
should fine a totally different way.

Regards, Niklas
Niklas Keller
Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
May 29, 2017 10:20PM
2017-05-29 16:03 GMT+02:00 Lauri Kenttä <lauri.kentta@gmail.com>:

> On 2017-05-29 13:58, Niklas Keller wrote:
>
>> I have updated the RFC to use a "min_signature_bits" setting instead.
>>
>
> At least that name is misleading. Most PHP users would probably wonder why
> a setting of 128 does not allow the 160-bit hash from SHA-1 or the 512-bit
> RSA. So the name should be more like "min_cryptographic_strength" (possibly
> prefixed with "signature_") to make it clear that this is not really about
> the bits in signature.
>
> I'm not totally convinced about this bit approach in general. What happens
> if SHA-2 is suddenly broken and people move to SHA-3 of the same length?
>

I'm open to better suggestions.

Regards, Niklas
Niklas Keller
[PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
May 30, 2017 08:00AM
Hi Jakub,

do you know how I can check whether a certificate is in the trust store or
not?

Regards, Niklas

2017-05-29 22:00 GMT+02:00 Jakub Zelenka <bukka@php.net>:

> On Mon, May 29, 2017 at 11:58 AM, Niklas Keller <me@kelunik.com> wrote:
>
>> Morning Internals,
>>
>> I have updated the RFC to use a "min_signature_bits" setting instead.
>>
>>
> Wouldn't be better use security levels instead as it is in OpenSSL? Of
> course I mean just for sig level to not re-implement everything. Basically
> having sig_level or something like that...
>
Jakub Zelenka
[PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
May 30, 2017 10:20PM
On Tue, May 30, 2017 at 6:51 AM, Niklas Keller <me@kelunik.com> wrote:

>
> do you know how I can check whether a certificate is in the trust store or
> not?
>
>
I guess it depends what you want to do. If you want to check if the cert is
in cert store loaded in the SSL struct, then you could get it using
SSL_get_client_CA_list and then check the resulted STACK_OF(X509_NAME). If
you know X509_STORE_CTX, then you should be able to get chain from it using
X509_STORE_CTX_get0_chain and then go through it. But not really sure what
fits best to your use case. I'd probably need look into OpenSSL internals
to see what would be the best solution.

Cheers

Jakub
Jakub Zelenka
[PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
May 30, 2017 10:30PM
On Mon, May 29, 2017 at 9:16 PM, Niklas Keller <me@kelunik.com> wrote:

> 2017-05-29 22:00 GMT+02:00 Jakub Zelenka <bukka@php.net>:
>
>> On Mon, May 29, 2017 at 11:58 AM, Niklas Keller <me@kelunik.com> wrote:
>>
>>> Morning Internals,
>>>
>>> I have updated the RFC to use a "min_signature_bits" setting instead.
>>>
>>>
>> Wouldn't be better use security levels instead as it is in OpenSSL? Of
>> course I mean just for sig level to not re-implement everything. Basically
>> having sig_level or something like that...
>>
>
> As we can't use the OpenSSL implementation directly, I don't see any
> reason to use arbitrary integers there which you have to look up again.
> Maybe we should fine a totally different way.
>
>
Well we are going to implement security levels at some point anyway as it
is the primary way how to control security strength in OpenSSL 1.1+ so
people will need to look it up anyway. It is also much easier to use than
directly setting security bits IMHO. It might also allow us to simplify
implementation in the future (for example if it gets separated to its own
verify param in the future, we could use that). Also we will be able to
just completely skip that if the main security level is already on that
level or higher (it would be already covered by that).

Please mind that this is an openssl extension so we should prefer the API
offered by the library and not trying to invent our own solutions.

Cheers

Jakub
Niklas Keller
[PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
July 03, 2017 03:20PM
2017-05-30 22:26 GMT+02:00 Jakub Zelenka <bukka@php.net>:

> On Mon, May 29, 2017 at 9:16 PM, Niklas Keller <me@kelunik.com> wrote:
>
>> 2017-05-29 22:00 GMT+02:00 Jakub Zelenka <bukka@php.net>:
>>
>>> On Mon, May 29, 2017 at 11:58 AM, Niklas Keller <me@kelunik.com> wrote:
>>>
>>>> Morning Internals,
>>>>
>>>> I have updated the RFC to use a "min_signature_bits" setting instead.
>>>>
>>>>
>>> Wouldn't be better use security levels instead as it is in OpenSSL? Of
>>> course I mean just for sig level to not re-implement everything. Basically
>>> having sig_level or something like that...
>>>
>>
>> As we can't use the OpenSSL implementation directly, I don't see any
>> reason to use arbitrary integers there which you have to look up again.
>> Maybe we should fine a totally different way.
>>
>>
> Well we are going to implement security levels at some point anyway as it
> is the primary way how to control security strength in OpenSSL 1.1+ so
> people will need to look it up anyway. It is also much easier to use than
> directly setting security bits IMHO. It might also allow us to simplify
> implementation in the future (for example if it gets separated to its own
> verify param in the future, we could use that). Also we will be able to
> just completely skip that if the main security level is already on that
> level or higher (it would be already covered by that).
>
> Please mind that this is an openssl extension so we should prefer the API
> offered by the library and not trying to invent our own solutions.
>
> Cheers
>
> Jakub
>

What's the way to proceed now? Time is running low for the PHP 7.2 feature
freeze.

I've implemented it manually for https://github.com/amphp/socket/pull/31
now. The captured chain always seems to contain the trusted certificate as
last certificate.

Honestly, what isn't secure for the public internet PKI shouldn't be
considered secure for other contexts. I'd personally be fine with not even
providing a setting other than disabling verify_peer.

Regards, Niklas
Anatol Belski
RE: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
July 03, 2017 07:00PM
Hi,

> -----Original Message-----
> From: Niklas Keller [mailto:me@kelunik.com]
> Sent: Monday, July 3, 2017 3:14 PM
> To: Jakub Zelenka <bukka@php.net>
> Cc: PHP Internals <internals@lists.php.net>
> Subject: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
>
> 2017-05-30 22:26 GMT+02:00 Jakub Zelenka <bukka@php.net>:
>
> > On Mon, May 29, 2017 at 9:16 PM, Niklas Keller <me@kelunik.com> wrote:
> >
> >> 2017-05-29 22:00 GMT+02:00 Jakub Zelenka <bukka@php.net>:
> >>
> >>> On Mon, May 29, 2017 at 11:58 AM, Niklas Keller <me@kelunik.com>
> wrote:
> >>>
> >>>> Morning Internals,
> >>>>
> >>>> I have updated the RFC to use a "min_signature_bits" setting instead.
> >>>>
> >>>>
> >>> Wouldn't be better use security levels instead as it is in OpenSSL?
> >>> Of course I mean just for sig level to not re-implement everything.
> >>> Basically having sig_level or something like that...
> >>>
> >>
> >> As we can't use the OpenSSL implementation directly, I don't see any
> >> reason to use arbitrary integers there which you have to look up again.
> >> Maybe we should fine a totally different way.
> >>
> >>
> > Well we are going to implement security levels at some point anyway
> > as it is the primary way how to control security strength in OpenSSL
> > 1.1+ so people will need to look it up anyway. It is also much easier
> > to use than directly setting security bits IMHO. It might also allow
> > us to simplify implementation in the future (for example if it gets
> > separated to its own verify param in the future, we could use that).
> > Also we will be able to just completely skip that if the main security
> > level is already on that level or higher (it would be already covered by that).
> >
> > Please mind that this is an openssl extension so we should prefer the
> > API offered by the library and not trying to invent our own solutions.
> >
> > Cheers
> >
> > Jakub
> >
>
> What's the way to proceed now? Time is running low for the PHP 7.2 feature
> freeze.
>
I haven't followed the discussion back then, but just read through. The discussion seems unfinished yet, as far as I understood. The two approaches - the one going by security levels, and the other using strength bits as a argument. As for me, security levels were more future oriented and the original alike, while have to be emulated with older dependencies. On the other hand - giving the strength directly is a an explicit approach, even if it's completely different from the latest OpenSSL. It were good to hear from Jakub yet.

About how to proceed - I'd say the issue is clear and either way should be fixed. The RFC chooses the explicit strength approach. What I'm a bit concerned about is, that there's no implementation by this time, neither for 7.2 nor for lower. Given there are indeed just last moments before the feature freeze, for 7.2 it depends on RMs.

In general, I'd prefer to see the discussion to come more or less to the conclusion about pro/contra of the concrete approach, especially from the POV different OpenSSL versions and future support. If a patch with an implementation could make it into 7.2, the backport for lower branches will have no choice regarding approach. But, without being able to look at th patch, it is hard to say, whether a backport is even doable. For example, how it often could be, an implementation of a new stream context option might require some additional struct member, etc. Alternatively, what could be done - bring the approach discussion and consequently the BC implementation in all of 7\.[012] while letting the restrictive part to target 7.3. Either way, please let's see the code.

Regards

Anatol
Niklas Keller
Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
July 03, 2017 07:20PM
>
> I haven't followed the discussion back then, but just read through. The
> discussion seems unfinished yet, as far as I understood. The two
> approaches - the one going by security levels, and the other using
> strength bits as a argument. As for me, security levels were more future
> oriented and the original alike, while have to be emulated with older
> dependencies. On the other hand - giving the strength directly is a an
> explicit approach, even if it's completely different from the latest
> OpenSSL. It were good to hear from Jakub yet.
>
> About how to proceed - I'd say the issue is clear and either way should be
> fixed. The RFC chooses the explicit strength approach. What I'm a bit
> concerned about is, that there's no implementation by this time, neither
> for 7.2 nor for lower. Given there are indeed just last moments before the
> feature freeze, for 7.2 it depends on RMs.
>

This is caused by the approach not being clear, I have an implementation
without options locally.


> In general, I'd prefer to see the discussion to come more or less to the
> conclusion about pro/contra of the concrete approach, especially from the
> POV different OpenSSL versions and future support. If a patch with an
> implementation could make it into 7.2, the backport for lower branches will
> have no choice regarding approach. But, without being able to look at th
> patch, it is hard to say, whether a backport is even doable. For example,
> how it often could be, an implementation of a new stream context option
> might require some additional struct member, etc. Alternatively, what could
> be done - bring the approach discussion and consequently the BC
> implementation in all of 7\.[012] while letting the restrictive part to
> target 7.3. Either way, please let's see the code.
>

I think the best approach for now would be that:

Add two new context options for the "ssl" wrapper:
"insecure_allow_md5_signature" and "insecure_allow_sha1_signature". They
will both default to false starting in PHP 7.2 while the backports to PHP
7.1 and 7.0 will default to true. Additionally there will be two INI
options which are only added to PHP 7.1 and 7.0 to allow people to
immediately upgrade to secure defaults without any risk of breaking other
apps.

Regards, Niklas
Sara Golemon
Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
July 03, 2017 07:30PM
On Mon, Jul 3, 2017 at 12:49 PM, Anatol Belski <weltling@outlook.de> wrote:
> About how to proceed - I'd say the issue is clear and either way
> should be fixed. The RFC chooses the explicit strength approach.
> What I'm a bit concerned about is, that there's no implementation
> by this time, neither for 7.2 nor for lower. Given there are indeed
> just last moments before the feature freeze, for 7.2 it depends on RMs.
>
I've told Niklas on Twitter, but I'll repeat here for the record. I
fully expect a rush of last-minute RFCs "urgently" needing an
extension of the feature freeze deadline. These come every new
release as people are shocked to discover that timetables exist.

IMO any RFC which does not have a merged implementation by July 20th*
should assume it's not making it into 7.2, however RFCs will be taken
on a case-by-case basis while in the beta period. As to this one: It
certainly seems important that we don't let users blindly ignore
terrible certificates. That's a false sense of security, and is
arguably worse than no security at all.

I expect to allow this RFC as far out as beta2 ASSUMING the
implementation is sensible enough to get a passing vote from
internals.

If it moves things along smoother/quicker, I would suggest to
constrain this discussion as though it were ONLY targeting 7.2, and we
can have a separate discussion about how/when it should be back-ported
to 7.1 and 7.0 since this change does represent a (theoretical**) BC
break.

-Sara

* Yes, this includes ext/sodium, and I'm less inclined to extend
lee-way to that for a number of reasons.
** Legitimately signed sites should not actually be a problem, AIUI.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sara Golemon
Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
July 03, 2017 07:30PM
On Mon, Jul 3, 2017 at 1:12 PM, Niklas Keller <me@kelunik.com> wrote:
> Additionally there will be two INI options
> which are only added to PHP 7.1 and 7.0 to allow people to immediately
> upgrade to secure defaults without any risk of breaking other apps.
>
I understand what you're going for there, but it's just a bit weird to
have that INI option exist for a weird pair of version ranges and not
forward. I'd say keep the INI in 7.2 and (perhaps) mark them
deprecated. There's no sense making that upgrade path unreasonably
difficult.

-Sara

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Niklas Keller
Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
July 03, 2017 08:20PM
2017-07-03 19:24 GMT+02:00 Sara Golemon <pollita@php.net>:

> On Mon, Jul 3, 2017 at 1:12 PM, Niklas Keller <me@kelunik.com> wrote:
> > Additionally there will be two INI options
> > which are only added to PHP 7.1 and 7.0 to allow people to immediately
> > upgrade to secure defaults without any risk of breaking other apps.
> >
> I understand what you're going for there, but it's just a bit weird to
> have that INI option exist for a weird pair of version ranges and not
> forward. I'd say keep the INI in 7.2 and (perhaps) mark them
> deprecated. There's no sense making that upgrade path unreasonably
> difficult.
>

True, but I'd like it to be an INI option to strengthen the security, but
not allow to weaken it. You really shouldn't use MD5 or SHA1 for TLS
certificates 2018 (!). If you really need it there, you can still set a
default stream context option, but we won't clutter the INI options of
future versions.

Regards, Niklas
Davey Shafik
Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
July 04, 2017 09:00AM
It should be noted that Certificate Authorities (CAs) haven't been issuing
SHA-1 certs since December 31st 2015.

I think the best solution if possible, would be to treat MD5 and SHA-1
certs as invalid in _all_ supported versions of PHP and requiring that
the verify_peer
option be set to false to accept them.

For PHP 7.2 also add deprecation notices.

For PHP 7.3 and later, remove support completely.

On Mon, Jul 3, 2017 at 11:11 AM, Niklas Keller <me@kelunik.com> wrote:

> 2017-07-03 19:24 GMT+02:00 Sara Golemon <pollita@php.net>:
>
> > On Mon, Jul 3, 2017 at 1:12 PM, Niklas Keller <me@kelunik.com> wrote:
> > > Additionally there will be two INI options
> > > which are only added to PHP 7.1 and 7.0 to allow people to immediately
> > > upgrade to secure defaults without any risk of breaking other apps.
> > >
> > I understand what you're going for there, but it's just a bit weird to
> > have that INI option exist for a weird pair of version ranges and not
> > forward. I'd say keep the INI in 7.2 and (perhaps) mark them
> > deprecated. There's no sense making that upgrade path unreasonably
> > difficult.
> >
>
> True, but I'd like it to be an INI option to strengthen the security, but
> not allow to weaken it. You really shouldn't use MD5 or SHA1 for TLS
> certificates 2018 (!). If you really need it there, you can still set a
> default stream context option, but we won't clutter the INI options of
> future versions.
>
> Regards, Niklas
>
Anatol Belski
RE: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
July 04, 2017 01:20PM
Hi Niklas,

> -----Original Message-----
> From: Niklas Keller [mailto:me@kelunik.com]
> Sent: Monday, July 3, 2017 7:13 PM
> To: Anatol Belski <weltling@outlook.de>; Sara Golemon <pollita@php.net>
> Cc: Jakub Zelenka <bukka@php.net>; PHP Internals <internals@lists.php.net>
> Subject: Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
>
> I think the best approach for now would be that:
>
> Add two new context options for the "ssl" wrapper:
> "insecure_allow_md5_signature" and "insecure_allow_sha1_signature". They
> will both default to false starting in PHP 7.2 while the backports to PHP 7.1 and
> 7.0 will default to true. Additionally there will be two INI options which are only
> added to PHP 7.1 and 7.0 to allow people to immediately upgrade to secure
> defaults without any risk of breaking other apps.
>
Same as Ferenc, I couldn't find anything in other languages but this about Java http://openjdk.java.net/jeps/288 . Seems a well thought approach and your suggestion about the stream context is similar.

Probably it is the minimum, whereby the JDK has more flexible options and more constraints, which might be too flexible for us.Anyway, users are more in control about more details, in PHP we still hide many details. For example, consider things like `RSA keySize < 1024`, it is solvable in PHP with the stream context option, but hardly through INI. And this one is fun `SHA1 usage SignedJAR & denyAfter 2017-01-01`, too.

Regards

Anatol

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Anatol Belski
RE: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
July 04, 2017 01:30PM
Hi Sara,

> -----Original Message-----
> From: php@golemon.com [mailto:php@golemon.com] On Behalf Of Sara
> Golemon
> Sent: Monday, July 3, 2017 7:22 PM
> To: Anatol Belski <weltling@outlook.de>
> Cc: Niklas Keller <me@kelunik.com>; Jakub Zelenka <bukka@php.net>; PHP
> Internals <internals@lists.php.net>
> Subject: Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
>
> On Mon, Jul 3, 2017 at 12:49 PM, Anatol Belski <weltling@outlook.de> wrote:
> > About how to proceed - I'd say the issue is clear and either way
> > should be fixed. The RFC chooses the explicit strength approach.
> > What I'm a bit concerned about is, that there's no implementation by
> > this time, neither for 7.2 nor for lower. Given there are indeed just
> > last moments before the feature freeze, for 7.2 it depends on RMs.
> >
> I've told Niklas on Twitter, but I'll repeat here for the record. I fully expect a
> rush of last-minute RFCs "urgently" needing an extension of the feature freeze
> deadline. These come every new release as people are shocked to discover that
> timetables exist.
>
With issues like this - d'accord. The early pre-release seems to be traditionally a peak time.

> IMO any RFC which does not have a merged implementation by July 20th*
> should assume it's not making it into 7.2, however RFCs will be taken on a case-
> by-case basis while in the beta period. As to this one: It certainly seems
> important that we don't let users blindly ignore terrible certificates. That's a
> false sense of security, and is arguably worse than no security at all.
>
> I expect to allow this RFC as far out as beta2 ASSUMING the implementation is
> sensible enough to get a passing vote from internals.
>
> If it moves things along smoother/quicker, I would suggest to constrain this
> discussion as though it were ONLY targeting 7.2, and we can have a separate
> discussion about how/when it should be back-ported to 7.1 and 7.0 since this
> change does represent a (theoretical**) BC break.
>
IMO for better compatibility, both "new" and "backport" should be seen together. It's clear a fix should come ASAP, but I'd see no reason to rush without a good consideration. That's why I was asking right about the code, as that's the most essential part. It is true, that some breaches are even allowed for security reasons, as per Ferenc, so we need to evaluate it by the matters of fact.

Thanks

Anatol


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Anatol Belski
RE: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
July 04, 2017 01:40PM
Hi,

> -----Original Message-----
> From: Niklas Keller [mailto:me@kelunik.com]
> Sent: Monday, July 3, 2017 8:12 PM
> To: Sara Golemon <pollita@php.net>
> Cc: Anatol Belski <weltling@outlook.de>; Jakub Zelenka <bukka@php.net>; PHP
> Internals <internals@lists.php.net>
> Subject: Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
>
> 2017-07-03 19:24 GMT+02:00 Sara Golemon <pollita@php.net
> <mailto:pollita@php.net> >:
>
>
> On Mon, Jul 3, 2017 at 1:12 PM, Niklas Keller <me@kelunik.com
> <mailto:me@kelunik.com> > wrote:
> > Additionally there will be two INI options
> > which are only added to PHP 7.1 and 7.0 to allow people to
> immediately
> > upgrade to secure defaults without any risk of breaking other apps.
> >
> I understand what you're going for there, but it's just a bit weird to
> have that INI option exist for a weird pair of version ranges and not
> forward. I'd say keep the INI in 7.2 and (perhaps) mark them
> deprecated. There's no sense making that upgrade path unreasonably
> difficult.
>
>
>
> True, but I'd like it to be an INI option to strengthen the security, but not allow
> to weaken it. You really shouldn't use MD5 or SHA1 for TLS certificates 2018 (!).
> If you really need it there, you can still set a default stream context option, but
> we won't clutter the INI options of future versions.
>
An INI option doesn't seem necessary. If there's a stream context option, the existing code has to be touched. Those who do it, know what they do. Same as with the other issue about TLS - stable branches, that have active users already, we shouldn't enforce the change, but just offer it.

I'd be also against an INI option in the sense it's being suggested, because it would be not useful in 7.2 and above. As you mention also, they may have the reverse effect in 7.2. The current RFC doesn't mention any INI, and I think it's too much inconsistency having both ini and stream context. As linked in the other mail, what we could do is introduce INI options only, Java alike, that would control the behavior same way in every branch. As much as almost no one likes new INI options, it would mean likely no backport were required. A stream context option sounds more plausible and future oriented to me, however.

Regards

Anatol

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sorry, only registered users may post in this forum.

Click here to login