Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC] Distrust SHA-1 Certificates »

[RFC] Distrust SHA-1 Certificates

php.internals

Niklas Keller

9 years ago
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

Stas Malyshev

9 years ago
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

Niklas Keller

9 years ago
> > 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

9 years ago
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

9 years ago
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

9 years ago
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

9 years ago
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

9 years ago
> > > 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

9 years ago
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

9 years ago
> > 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

Jan Ehrhardt

9 years ago
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

Jan Ehrhardt

9 years ago
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

Niklas Keller

9 years ago
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>:

Lauri Kenttä

9 years ago
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ä

Niklas Keller

9 years ago
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

Jakub Zelenka

9 years ago
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

9 years ago
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

Jakub Zelenka

9 years ago
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

9 years ago
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

9 years ago
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

9 years ago
> > 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

9 years ago
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

Niklas Keller

9 years ago
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

9 years ago
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

Niklas Keller

9 years ago
2017-07-04 13:11 GMT+02:00 Anatol Belski <weltling@outlook.de>:
> 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. >
I asked in #python-dev on Freenode yesterday. The response I got was that it's something on the TODO list, but they don't see it as high priority and the person I talked to said it would only be a defense-in-depth, which it is not, it's a vulnerability.
> 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, Niklas

Sara Golemon

9 years ago
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.

Anatol Belski

9 years ago
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

Niklas Keller

9 years ago
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>:

Jakub Zelenka

9 years ago
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