[RFC] Distrust SHA-1 Certificates

  97200
November 26, 2016 15:49 me@kelunik.com (Niklas Keller)
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
  97202
November 26, 2016 21:06 smalyshev@gmail.com (Stanislav Malyshev)
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
  97204
November 27, 2016 10:38 me@kelunik.com (Niklas Keller)
> > 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
  97205
November 27, 2016 13:06 bukka@php.net (Jakub Zelenka)
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
  97206
November 27, 2016 13:09 bukka@php.net (Jakub Zelenka)
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...
  97207
November 27, 2016 14:22 me@kelunik.com (Niklas Keller)
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
  97208
November 27, 2016 15:10 bukka@php.net (Jakub Zelenka)
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
  97209
November 27, 2016 15:17 me@kelunik.com (Niklas Keller)
> > > 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
  97210
November 27, 2016 19:37 bukka@php.net (Jakub Zelenka)
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
  97211
November 27, 2016 20:28 me@kelunik.com (Niklas Keller)
> > 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 >
  99227
May 29, 2017 10:58 me@kelunik.com (Niklas Keller)
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 >
  99231
May 29, 2017 14:03 lauri.kentta@gmail.com (=?UTF-8?Q?Lauri_Kentt=C3=A4?=)
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ä
  99238
May 29, 2017 20:17 me@kelunik.com (Niklas Keller)
2017-05-29 16:03 GMT+02:00 Lauri Kenttä 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
  99235
May 29, 2017 20:00 bukka@php.net (Jakub Zelenka)
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...
  99237
May 29, 2017 20:16 me@kelunik.com (Niklas Keller)
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
  99284
May 30, 2017 20:26 bukka@php.net (Jakub Zelenka)
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
  99701
July 3, 2017 13:13 me@kelunik.com (Niklas Keller)
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
  99717
July 3, 2017 16:49 weltling@outlook.de (Anatol Belski)
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
  99718
July 3, 2017 17:12 me@kelunik.com (Niklas Keller)
> > 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
  99723
July 3, 2017 17:24 pollita@php.net (Sara Golemon)
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
  99724
July 3, 2017 18:11 me@kelunik.com (Niklas Keller)
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
  99732
July 4, 2017 06:53 davey@php.net (Davey Shafik)
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 >
  99763
July 5, 2017 13:29 weltling@outlook.de (Anatol Belski)
Hi Davey,

> -----Original Message----- > From: me@daveyshafik.com [mailto:me@daveyshafik.com] On Behalf Of Davey > Shafik > Sent: Tuesday, July 4, 2017 8:53 AM > To: Niklas Keller <me@kelunik.com> > Cc: Sara Golemon <pollita@php.net>; 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 > > 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. > Wouldn't verify_peer introduce another issue, that not only md5 and sha1 but also any certs would be accepted, that normally shouldn't be?
Regards Anatol
  99739
July 4, 2017 11:33 weltling@outlook.de (Anatol Belski)
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
  99744
July 4, 2017 18:20 me@kelunik.com (Niklas Keller)
2017-07-04 13:33 GMT+02:00 Anatol Belski <weltling@outlook.de>:

> 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. >
The issue without INI option is that it requires a code change. We can't just tell people "better apply this configuration change to have secure TLS". I'd definitely want this to be enabled _everywhere_.
> 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.
We can prevent the reverse effect by ignoring it if it has bad security effects.
> The current RFC doesn't mention any INI, and I think it's too much > inconsistency having both ini and stream context.
Forget about everything that's in the RFC about the actual implementation. It's an older idea that needs to be updated based on what's suggested and seems acceptable.
> 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.
You still need to backport it then.
> A stream context option sounds more plausible and future oriented to me, > however.
Regards, Niklas
  99747
July 4, 2017 20:19 weltling@outlook.de (Anatol Belski)
> -----Original Message----- > From: Niklas Keller [mailto:me@kelunik.com] > Sent: Tuesday, July 4, 2017 8:21 PM > To: Anatol Belski <weltling@outlook.de> > Cc: Sara Golemon <pollita@php.net>; Jakub Zelenka <bukka@php.net>; PHP > Internals <internals@lists.php.net> > Subject: Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates > > 2017-07-04 13:33 GMT+02:00 Anatol Belski <weltling@outlook.de > <mailto:weltling@outlook.de> >: > > 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. > > > > The issue without INI option is that it requires a code change. We can't just tell > people "better apply this configuration change to have secure TLS". I'd definitely > want this to be enabled _everywhere_. > > > 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. > > > We can prevent the reverse effect by ignoring it if it has bad security effects. > > > The current RFC doesn't mention any INI, and I think it's too much > inconsistency having both ini and stream context. > > > Forget about everything that's in the RFC about the actual implementation. It's > an older idea that needs to be updated based on what's suggested and seems > acceptable. > But the RFC is what you wrote about some days ago. Anything I told is based on the RFC and the previous conversations. My understanding was, that you were intended to push the exact RFC to vote. If you tell now there's no approach and the RFC has to be ignored, then it doesn't help. If there's another approach, so please present it.
Regards Anatol
  99748
July 4, 2017 21:13 me@kelunik.com (Niklas Keller)
> > But the RFC is what you wrote about some days ago. Anything I told is > based on the RFC and the previous conversations. My understanding was, that > you were intended to push the exact RFC to vote. If you tell now there's no > approach and the RFC has to be ignored, then it doesn't help. If there's > another approach, so please present it.
Nobody wants to backport OpenSSL's implementation, so I don't see the viability of supporting `auth_level`. I've outlined my current suggestion several mails ago: ----- 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
  99750
July 4, 2017 21:33 weltling@outlook.de (Anatol Belski)
> -----Original Message----- > From: Niklas Keller [mailto:me@kelunik.com] > Sent: Tuesday, July 4, 2017 11:14 PM > To: Anatol Belski <weltling@outlook.de> > Cc: Sara Golemon <pollita@php.net>; Jakub Zelenka <bukka@php.net>; PHP > Internals <internals@lists.php.net> > Subject: Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates > > But the RFC is what you wrote about some days ago. Anything I told is > based on the RFC and the previous conversations. My understanding was, that > you were intended to push the exact RFC to vote. If you tell now there's no > approach and the RFC has to be ignored, then it doesn't help. If there's another > approach, so please present it. > > > Nobody wants to backport OpenSSL's implementation, so I don't see the viability > of supporting `auth_level`. > > I've outlined my current suggestion several mails ago: > > ----- > 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. > ----- Ok, so that's where the cat catches its tail. If there are both INI and wrapper options, doing the same, it were excessive. Say, if the context option has to be integrated anyway, why INI? Otherwise, if INI is supposed to provide same separately, without touching the code - why bother with stream context? Or in further, if the INI is supposed to be ignored in 7.2, then the code still has to be changed. The more complicated, the more inconsistent.
Thanks.
  99754
July 5, 2017 07:42 me@kelunik.com (Niklas Keller)
> > > But the RFC is what you wrote about some days ago. Anything I told > is > > based on the RFC and the previous conversations. My understanding was, > that > > you were intended to push the exact RFC to vote. If you tell now there's > no > > approach and the RFC has to be ignored, then it doesn't help. If there's > another > > approach, so please present it. > > > > > > Nobody wants to backport OpenSSL's implementation, so I don't see the > viability > > of supporting `auth_level`. > > > > I've outlined my current suggestion several mails ago: > > > > ----- > > 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. > > ----- > Ok, so that's where the cat catches its tail. If there are both INI and > wrapper options, doing the same, it were excessive. Say, if the context > option has to be integrated anyway, why INI? Otherwise, if INI is supposed > to provide same separately, without touching the code - why bother with > stream context? Or in further, if the INI is supposed to be ignored in 7.2, > then the code still has to be changed. The more complicated, the more > inconsistent. >
If we choose to block SHA1 and MD5 certificates by default in 7.0 / 7.1, then we don't need the INI option. But if you decide it's not acceptable as an important security fix, then I definitely want a way to secure all applications at once with a configuration change instead of having to change each and every application to set a default stream context option. Regards, Niklas
  99762
July 5, 2017 13:28 weltling@outlook.de (Anatol Belski)
Hi,

> -----Original Message----- > From: Niklas Keller [mailto:me@kelunik.com] > Sent: Wednesday, July 5, 2017 9:43 AM > To: Anatol Belski <weltling@outlook.de> > Cc: Sara Golemon <pollita@php.net>; Jakub Zelenka <bukka@php.net>; PHP > Internals <internals@lists.php.net> > Subject: Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates > > > But the RFC is what you wrote about some days ago. Anything I > told is > > based on the RFC and the previous conversations. My understanding > was, that > > you were intended to push the exact RFC to vote. If you tell now > there's no > > approach and the RFC has to be ignored, then it doesn't help. If there's > another > > approach, so please present it. > > > > > > Nobody wants to backport OpenSSL's implementation, so I don't see > the viability > > of supporting `auth_level`. > > > > I've outlined my current suggestion several mails ago: > > > > ----- > > 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. > > ----- > Ok, so that's where the cat catches its tail. If there are both INI and > wrapper options, doing the same, it were excessive. Say, if the context option > has to be integrated anyway, why INI? Otherwise, if INI is supposed to provide > same separately, without touching the code - why bother with stream context? > Or in further, if the INI is supposed to be ignored in 7.2, then the code still has to > be changed. The more complicated, the more inconsistent. > > > > If we choose to block SHA1 and MD5 certificates by default in 7.0 / 7.1, then we > don't need the INI option. But if you decide it's not acceptable as an important > security fix, then I definitely want a way to secure all applications at once with a > configuration change instead of having to change each and every application to > set a default stream context option. > Ok, so you strive to create a completely new RFC with a solution based on today's situation. I think you still don't see my point. Say there's insecure_allow_sha1_signature, which is a stream context. Then
- in 7.0 and 7.1 - if absent, insecure_allow_sha1_signature = true - if present, the given value taken - impact for 7.2 migration - if explicit insecure_allow_sha1_signature = false is in the code, no impact - in 7.2 - if absent, insecure_allow_sha1_signature = false - if present, depending on the decision either the exact value is taken or ignored - future impact - none, the option can be even silently removed - in 7.3 - removed and disabled completely No see same if insecure_allow_sha1_signature is an INI - in 7.0 and 7.1 - if not set, insecure_allow_sha1_signature = On - if set, the given value is taken - impact for 7.2 migration - depending on decision, either it's deprecated warning or disabled by default - in 7.2 - if not set, insecure_allow_sha1_signature = Off - if set, the given value is taken, warning is issued - in 7.3 - removed and disabled completely Both options do same, but in different manner. Both have advantages and downsides, but one option only is both necessary and sufficient to achieve the goal. In further - of course, blocking anything by default can be a vote option, no question. Say like by the context option, always go by the 7.2 variant. However I'd see a little sense to disabling sha1 and md5 signed certs completely. There still can be users, that trust their self-signed certificates and that can work indefinitely, whether it is good or not. This especially can concern older systems and organizations perhaps having intranet apps. In case of a complete ban, another issue would be - there's no choice other than to stay by an outdated PHP version without any chance to upgrade, except manually patching it. This is something that should not happen within a stable release line that supports older systems. See for example this link https://social.technet.microsoft.com/wiki/contents/articles/32288.windows-enforcement-of-sha1-certificates.aspx . Regards Anatol
  99765
July 5, 2017 14:38 me@kelunik.com (Niklas Keller)
> > Ok, so you strive to create a completely new RFC with a solution based on > today's situation. I think you still don't see my point. Say there's > insecure_allow_sha1_signature, which is a stream context. Then > > - in 7.0 and 7.1 > - if absent, insecure_allow_sha1_signature = true > - if present, the given value taken > - impact for 7.2 migration - if explicit insecure_allow_sha1_signature = > false is in the code, no impact > - in 7.2 > - if absent, insecure_allow_sha1_signature = false > - if present, depending on the decision either the exact value is taken > or ignored > - future impact - none, the option can be even silently removed > - in 7.3 > - removed and disabled completely > > No see same if insecure_allow_sha1_signature is an INI > > - in 7.0 and 7.1 > - if not set, insecure_allow_sha1_signature = On > - if set, the given value is taken > - impact for 7.2 migration - depending on decision, either it's > deprecated warning or disabled by default > - in 7.2 > - if not set, insecure_allow_sha1_signature = Off > - if set, the given value is taken, warning is issued > - in 7.3 > - removed and disabled completely > > Both options do same, but in different manner. Both have advantages and > downsides, but one option only is both necessary and sufficient to achieve > the goal. >
You plan assumes we'll disallow sha1 / md5 completely in the future, dunno whether that'll be the case. I'd prefer that.
> In further - of course, blocking anything by default can be a vote option, > no question. Say like by the context option, always go by the 7.2 variant. > However I'd see a little sense to disabling sha1 and md5 signed certs > completely. There still can be users, that trust their self-signed > certificates and that can work indefinitely, whether it is good or not.
The signature scheme won't be checked on trusted certificates, because it doesn't have an impact there. Trusted certificates are trusted by the public key in the trust store, not by the signature of a certificate.
> This especially can concern older systems and organizations perhaps having > intranet apps. In case of a complete ban, another issue would be - there's > no choice other than to stay by an outdated PHP version without any chance > to upgrade, except manually patching it. This is something that should not > happen within a stable release line that supports older systems. See for > example this link https://social.technet.microsoft.com/wiki/contents/ > articles/32288.windows-enforcement-of-sha1-certificates.aspx . >
Regards, Niklas
  99797
July 6, 2017 14:52 weltling@outlook.de (Anatol Belski)
Morning, guys,

> -----Original Message----- > From: Niklas Keller [mailto:me@kelunik.com] > Sent: Wednesday, July 5, 2017 4:39 PM > To: Anatol Belski <weltling@outlook.de> > Cc: Sara Golemon <pollita@php.net>; Jakub Zelenka <bukka@php.net>; PHP > Internals <internals@lists.php.net> > Subject: Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates > > Ok, so you strive to create a completely new RFC with a solution based > on today's situation. I think you still don't see my point. Say there's > insecure_allow_sha1_signature, which is a stream context. Then > > > - in 7.0 and 7.1 > - if absent, insecure_allow_sha1_signature = true > - if present, the given value taken > - impact for 7.2 migration - if explicit insecure_allow_sha1_signature = > false is in the code, no impact > - in 7.2 > - if absent, insecure_allow_sha1_signature = false > - if present, depending on the decision either the exact value is taken > or ignored > - future impact - none, the option can be even silently removed > - in 7.3 > - removed and disabled completely > > No see same if insecure_allow_sha1_signature is an INI > > - in 7.0 and 7.1 > - if not set, insecure_allow_sha1_signature = On > - if set, the given value is taken > - impact for 7.2 migration - depending on decision, either it's > deprecated warning or disabled by default > - in 7.2 > - if not set, insecure_allow_sha1_signature = Off > - if set, the given value is taken, warning is issued > - in 7.3 > - removed and disabled completely > > Both options do same, but in different manner. Both have advantages > and downsides, but one option only is both necessary and sufficient to achieve > the goal. > > > > You plan assumes we'll disallow sha1 / md5 completely in the future, dunno > whether that'll be the case. I'd prefer that. > Nome, that's not mine, it's was your intention as I've remembered, might be wrong. Anyway, what I wanted is only to show the redundancy having multiple ways to do same.
Anyway, now that Jakub also responded with an approach as well, maybe it's time to get an RFC get the thing done? It could have the two suggestions brought till now as an "exclusive or" choice and the disablement plan. The one that won would be followed up. An implementation were great to have before. Both suggestions, either the separate context options for md5 and sha1, or security levels, do same job and only differ in the way it's done. The downside of security levels is, that fe the suggested security level 2 will disable both, while user might want to disable only sha1, that's where the separate options win on flexibility. Whereby having a higher security level should automatically ensure a certain weak functionality is disabled at once, which has some use as well. IMO, the INI option is a no go - the argument that user can get everything done at once breaks encapsulation, as not every stream in the app might require it. The plan about the default disablement by version brought by Jakub sounds plausible, as for me. IMHO the complete disablement should not be a part of this RFC. I would suggest, it's time to get on RFC and bust this issue. It would be great, if all the interested parties could cooperate on this. Thanks Anatol
  99824
July 10, 2017 20:54 weltling@outlook.de (Anatol Belski)
Hi,

> -----Original Message----- > From: Anatol Belski [mailto:weltling@outlook.de] > Sent: Thursday, July 6, 2017 4:52 PM > To: Niklas Keller <me@kelunik.com> > Cc: Sara Golemon <pollita@php.net>; Jakub Zelenka <bukka@php.net>; PHP > Internals <internals@lists.php.net> > Subject: RE: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates > > Morning, guys, > > > -----Original Message----- > > From: Niklas Keller [mailto:me@kelunik.com] > > Sent: Wednesday, July 5, 2017 4:39 PM > > To: Anatol Belski <weltling@outlook.de> > > Cc: Sara Golemon <pollita@php.net>; Jakub Zelenka <bukka@php.net>; PHP > > Internals <internals@lists.php.net> > > Subject: Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates > > > > Ok, so you strive to create a completely new RFC with a solution > > based on today's situation. I think you still don't see my point. Say > > there's insecure_allow_sha1_signature, which is a stream context. Then > > > > > > - in 7.0 and 7.1 > > - if absent, insecure_allow_sha1_signature = true > > - if present, the given value taken > > - impact for 7.2 migration - if explicit > > insecure_allow_sha1_signature = false is in the code, no impact > > - in 7.2 > > - if absent, insecure_allow_sha1_signature = false > > - if present, depending on the decision either the exact value is > > taken or ignored > > - future impact - none, the option can be even silently removed > > - in 7.3 > > - removed and disabled completely > > > > No see same if insecure_allow_sha1_signature is an INI > > > > - in 7.0 and 7.1 > > - if not set, insecure_allow_sha1_signature = On > > - if set, the given value is taken > > - impact for 7.2 migration - depending on decision, either it's > > deprecated warning or disabled by default > > - in 7.2 > > - if not set, insecure_allow_sha1_signature = Off > > - if set, the given value is taken, warning is issued > > - in 7.3 > > - removed and disabled completely > > > > Both options do same, but in different manner. Both have advantages > > and downsides, but one option only is both necessary and sufficient to > > achieve the goal. > > > > > > > > You plan assumes we'll disallow sha1 / md5 completely in the future, > > dunno whether that'll be the case. I'd prefer that. > > > Nome, that's not mine, it's was your intention as I've remembered, might be > wrong. Anyway, what I wanted is only to show the redundancy having multiple > ways to do same. > > Anyway, now that Jakub also responded with an approach as well, maybe it's > time to get an RFC get the thing done? It could have the two suggestions > brought till now as an "exclusive or" choice and the disablement plan. The one > that won would be followed up. An implementation were great to have before. > > Both suggestions, either the separate context options for md5 and sha1, or > security levels, do same job and only differ in the way it's done. The downside of > security levels is, that fe the suggested security level 2 will disable both, while > user might want to disable only sha1, that's where the separate options win on > flexibility. Whereby having a higher security level should automatically ensure a > certain weak functionality is disabled at once, which has some use as well. IMO, > the INI option is a no go - the argument that user can get everything done at > once breaks encapsulation, as not every stream in the app might require it. > > The plan about the default disablement by version brought by Jakub sounds > plausible, as for me. IMHO the complete disablement should not be a part of this > RFC. > > I would suggest, it's time to get on RFC and bust this issue. It would be great, if > all the interested parties could cooperate on this. > Any news on the topic?
Regards Anatol
  99836
July 11, 2017 16:34 bukka@php.net (Jakub Zelenka)
On Mon, Jul 10, 2017 at 9:54 PM, Anatol Belski <weltling@outlook.de> wrote:

> Hi, > > > -----Original Message----- > > From: Anatol Belski [mailto:weltling@outlook.de] > > Sent: Thursday, July 6, 2017 4:52 PM > > To: Niklas Keller <me@kelunik.com> > > Cc: Sara Golemon <pollita@php.net>; Jakub Zelenka <bukka@php.net>; PHP > > Internals <internals@lists.php.net> > > Subject: RE: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates > > > > Morning, guys, > > > > > -----Original Message----- > > > From: Niklas Keller [mailto:me@kelunik.com] > > > Sent: Wednesday, July 5, 2017 4:39 PM > > > To: Anatol Belski <weltling@outlook.de> > > > Cc: Sara Golemon <pollita@php.net>; Jakub Zelenka <bukka@php.net>; PHP > > > Internals <internals@lists.php.net> > > > Subject: Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates > > > > > > Ok, so you strive to create a completely new RFC with a solution > > > based on today's situation. I think you still don't see my point. Say > > > there's insecure_allow_sha1_signature, which is a stream context. Then > > > > > > > > > - in 7.0 and 7.1 > > > - if absent, insecure_allow_sha1_signature = true > > > - if present, the given value taken > > > - impact for 7.2 migration - if explicit > > > insecure_allow_sha1_signature = false is in the code, no impact > > > - in 7.2 > > > - if absent, insecure_allow_sha1_signature = false > > > - if present, depending on the decision either the exact value is > > > taken or ignored > > > - future impact - none, the option can be even silently removed > > > - in 7.3 > > > - removed and disabled completely > > > > > > No see same if insecure_allow_sha1_signature is an INI > > > > > > - in 7.0 and 7.1 > > > - if not set, insecure_allow_sha1_signature = On > > > - if set, the given value is taken > > > - impact for 7.2 migration - depending on decision, either it's > > > deprecated warning or disabled by default > > > - in 7.2 > > > - if not set, insecure_allow_sha1_signature = Off > > > - if set, the given value is taken, warning is issued > > > - in 7.3 > > > - removed and disabled completely > > > > > > Both options do same, but in different manner. Both have advantages > > > and downsides, but one option only is both necessary and sufficient to > > > achieve the goal. > > > > > > > > > > > > You plan assumes we'll disallow sha1 / md5 completely in the future, > > > dunno whether that'll be the case. I'd prefer that. > > > > > Nome, that's not mine, it's was your intention as I've remembered, might > be > > wrong. Anyway, what I wanted is only to show the redundancy having > multiple > > ways to do same. > > > > Anyway, now that Jakub also responded with an approach as well, maybe > it's > > time to get an RFC get the thing done? It could have the two suggestions > > brought till now as an "exclusive or" choice and the disablement plan. > The one > > that won would be followed up. An implementation were great to have > before. > > > > Both suggestions, either the separate context options for md5 and sha1, > or > > security levels, do same job and only differ in the way it's done. The > downside of > > security levels is, that fe the suggested security level 2 will disable > both, while > > user might want to disable only sha1, that's where the separate options > win on > > flexibility. Whereby having a higher security level should automatically > ensure a > > certain weak functionality is disabled at once, which has some use as > well. IMO, > > the INI option is a no go - the argument that user can get everything > done at > > once breaks encapsulation, as not every stream in the app might require > it. > > > > The plan about the default disablement by version brought by Jakub sounds > > plausible, as for me. IMHO the complete disablement should not be a part > of this > > RFC. > > > > I would suggest, it's time to get on RFC and bust this issue. It would > be great, if > > all the interested parties could cooperate on this. > > > Any news on the topic? > > After reading related discussion on openssl-users [1], I'm not so sure if
we should be doing that at all... Especially I agree with this bit: "Making your code more complex is a far higher risk than a practical certificate forgery based on a collision attack on SHA-1. " The only thing, that makes sense IMHO would be adding support for setting security level only for OpenSSL 1.1. [1] http://openssl.6102.n7.nabble.com/Rejecting-SHA-1-certificates-td71439.html Cheers Jakub
  99838
July 11, 2017 17:11 me@kelunik.com (Niklas Keller)
2017-07-11 18:34 GMT+02:00 Jakub Zelenka <bukka@php.net>:

> On Mon, Jul 10, 2017 at 9:54 PM, Anatol Belski <weltling@outlook.de> > wrote: > > > Hi, > > > > > -----Original Message----- > > > From: Anatol Belski [mailto:weltling@outlook.de] > > > Sent: Thursday, July 6, 2017 4:52 PM > > > To: Niklas Keller <me@kelunik.com> > > > Cc: Sara Golemon <pollita@php.net>; Jakub Zelenka <bukka@php.net>; PHP > > > Internals <internals@lists.php.net> > > > Subject: RE: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates > > > > > > Morning, guys, > > > > > > > -----Original Message----- > > > > From: Niklas Keller [mailto:me@kelunik.com] > > > > Sent: Wednesday, July 5, 2017 4:39 PM > > > > To: Anatol Belski <weltling@outlook.de> > > > > Cc: Sara Golemon <pollita@php.net>; Jakub Zelenka <bukka@php.net>; > PHP > > > > Internals <internals@lists.php.net> > > > > Subject: Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates > > > > > > > > Ok, so you strive to create a completely new RFC with a solution > > > > based on today's situation. I think you still don't see my point. Say > > > > there's insecure_allow_sha1_signature, which is a stream context. > Then > > > > > > > > > > > > - in 7.0 and 7.1 > > > > - if absent, insecure_allow_sha1_signature = true > > > > - if present, the given value taken > > > > - impact for 7.2 migration - if explicit > > > > insecure_allow_sha1_signature = false is in the code, no impact > > > > - in 7.2 > > > > - if absent, insecure_allow_sha1_signature = false > > > > - if present, depending on the decision either the exact value > is > > > > taken or ignored > > > > - future impact - none, the option can be even silently removed > > > > - in 7.3 > > > > - removed and disabled completely > > > > > > > > No see same if insecure_allow_sha1_signature is an INI > > > > > > > > - in 7.0 and 7.1 > > > > - if not set, insecure_allow_sha1_signature = On > > > > - if set, the given value is taken > > > > - impact for 7.2 migration - depending on decision, either it's > > > > deprecated warning or disabled by default > > > > - in 7.2 > > > > - if not set, insecure_allow_sha1_signature = Off > > > > - if set, the given value is taken, warning is issued > > > > - in 7.3 > > > > - removed and disabled completely > > > > > > > > Both options do same, but in different manner. Both have > advantages > > > > and downsides, but one option only is both necessary and sufficient > to > > > > achieve the goal. > > > > > > > > > > > > > > > > You plan assumes we'll disallow sha1 / md5 completely in the future, > > > > dunno whether that'll be the case. I'd prefer that. > > > > > > > Nome, that's not mine, it's was your intention as I've remembered, > might > > be > > > wrong. Anyway, what I wanted is only to show the redundancy having > > multiple > > > ways to do same. > > > > > > Anyway, now that Jakub also responded with an approach as well, maybe > > it's > > > time to get an RFC get the thing done? It could have the two > suggestions > > > brought till now as an "exclusive or" choice and the disablement plan. > > The one > > > that won would be followed up. An implementation were great to have > > before. > > > > > > Both suggestions, either the separate context options for md5 and sha1, > > or > > > security levels, do same job and only differ in the way it's done. The > > downside of > > > security levels is, that fe the suggested security level 2 will disable > > both, while > > > user might want to disable only sha1, that's where the separate options > > win on > > > flexibility. Whereby having a higher security level should > automatically > > ensure a > > > certain weak functionality is disabled at once, which has some use as > > well. IMO, > > > the INI option is a no go - the argument that user can get everything > > done at > > > once breaks encapsulation, as not every stream in the app might require > > it. > > > > > > The plan about the default disablement by version brought by Jakub > sounds > > > plausible, as for me. IMHO the complete disablement should not be a > part > > of this > > > RFC. > > > > > > I would suggest, it's time to get on RFC and bust this issue. It would > > be great, if > > > all the interested parties could cooperate on this. > > > > > Any news on the topic? > > > > > After reading related discussion on openssl-users [1], I'm not so sure if > we should be doing that at all... > > Especially I agree with this bit: > > "Making your code more complex is a far higher risk than a practical > certificate forgery based on a collision attack on SHA-1. " > > The only thing, that makes sense IMHO would be adding support for setting > security level only for OpenSSL 1.1. > > [1] > http://openssl.6102.n7.nabble.com/Rejecting-SHA-1- > certificates-td71439.html
Same here actually. While it's trivial to implement with OpenSSL 1.1, it's non-trivial before, because there's no API to get the trusted chain AFAIK, so we would indeed have to do this inside verify_callback. I'm not sure how high the risk actually is. Regards, Niklas
  99870
July 13, 2017 11:20 weltling@outlook.de (Anatol Belski)
Hi,

> After reading related discussion on openssl-users [1], I'm not so sure if > we should be doing that at all... > > Especially I agree with this bit: > > "Making your code more complex is a far higher risk than a practical > certificate forgery based on a collision attack on SHA-1. " > > The only thing, that makes sense IMHO would be adding support for > setting > security level only for OpenSSL 1.1. > > [1] > http://openssl.6102.n7.nabble.com/Rejecting-SHA-1-certificates- > td71439.html <http://openssl.6102.n7.nabble.com/Rejecting-SHA-1- > certificates-td71439.html> > > > Same here actually. While it's trivial to implement with OpenSSL 1.1, it's non- > trivial before, because there's no API to get the trusted chain AFAIK, so we > would indeed have to do this inside verify_callback. > Thanks for the responses and for the discussion link. With that, the situation is simplified a lot. This allows for a better conceived patch and there's obviously no strong reason to touch the stable branches.
Thanks. Anatol
  99878
July 17, 2017 07:58 me@kelunik.com (Niklas Keller)
> > Hi, > > > After reading related discussion on openssl-users [1], I'm not so > sure if > > we should be doing that at all... > > > > Especially I agree with this bit: > > > > "Making your code more complex is a far higher risk than a > practical > > certificate forgery based on a collision attack on SHA-1. " > > > > The only thing, that makes sense IMHO would be adding support for > > setting > > security level only for OpenSSL 1.1. > > > > [1] > > http://openssl.6102.n7.nabble.com/Rejecting-SHA-1-certificates- > > td71439.html <http://openssl.6102.n7.nabble.com/Rejecting-SHA-1- > > certificates-td71439.html> > > > > > > Same here actually. While it's trivial to implement with OpenSSL 1.1, > it's non- > > trivial before, because there's no API to get the trusted chain AFAIK, > so we > > would indeed have to do this inside verify_callback. > > > Thanks for the responses and for the discussion link. With that, the > situation is simplified a lot. This allows for a better conceived patch and > there's obviously no strong reason to touch the stable branches. > > Thanks. > > Anatol >
@Jakub: Do we want to expose "auth_level" then in case PHP is linked against OpenSSL 1.1.0+? Regards, Niklas
  99882
July 17, 2017 16:50 bukka@php.net (Jakub Zelenka)
Hey,

On Mon, Jul 17, 2017 at 8:58 AM, Niklas Keller <me@kelunik.com> wrote:

> Hi, >> >> > After reading related discussion on openssl-users [1], I'm not so >> sure if >> > we should be doing that at all... >> > >> > Especially I agree with this bit: >> > >> > "Making your code more complex is a far higher risk than a >> practical >> > certificate forgery based on a collision attack on SHA-1. " >> > >> > The only thing, that makes sense IMHO would be adding support for >> > setting >> > security level only for OpenSSL 1.1. >> > >> > [1] >> > http://openssl.6102.n7.nabble.com/Rejecting-SHA-1-certificates- >> > td71439.html <http://openssl.6102.n7.nabble.com/Rejecting-SHA-1- >> > certificates-td71439.html> >> > >> > >> > Same here actually. While it's trivial to implement with OpenSSL 1.1, >> it's non- >> > trivial before, because there's no API to get the trusted chain AFAIK, >> so we >> > would indeed have to do this inside verify_callback. >> > >> Thanks for the responses and for the discussion link. With that, the >> situation is simplified a lot. This allows for a better conceived patch and >> there's obviously no strong reason to touch the stable branches. >> >> Thanks. >> >> Anatol >> > > @Jakub: Do we want to expose "auth_level" then in case PHP is linked > against OpenSSL 1.1.0+? > > > I just pushed support for security_level [1] which is more comprehensive
and the patch is also very simple. Apology for such last minute addition but I felt that it is really useful for 7.2 and I have already messaged about that and haven't heard any objections. Of course if anyone feels strongly against it, I will be happy to reconsider it. Cheers Jakub
  99761
July 5, 2017 13:23 bukka@php.net (Jakub Zelenka)
Hi,

On Tue, Jul 4, 2017 at 10:13 PM, Niklas Keller <me@kelunik.com> wrote:

> But the RFC is what you wrote about some days ago. Anything I told is >> based on the RFC and the previous conversations. My understanding was, that >> you were intended to push the exact RFC to vote. If you tell now there's no >> approach and the RFC has to be ignored, then it doesn't help. If there's >> another approach, so please present it. > > > Nobody wants to backport OpenSSL's implementation, so I don't see the > viability of supporting `auth_level`. > > Backporting auth_level would be overkill but we could add a sig_level as I said previously. It would simplify many things in the future and address
exactly the issue. Setting explicit options named by algorithm is not flexible and after couple of years it will be just an ugly unused leftover from past...
> I've outlined my current suggestion several mails ago: > > ----- > 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. > ----- > > I don't like adding new INI in general. It won't really help because people
won't usually set it and changing behavior in such way is not good IMHO. To sum it up I'd really prefer solution based on security level (in this case just a sig_level part of it) and have it just as a context option which could be backported in the following way: 7.0 - default to 0 (the same behavior as now to be safe) 7.1 - default to 1 (80 bits of security and more - disable md5 as it shouldn't break too many apps and at least protect against md5 signed certs). 7.2 - default to 2 (SHA-1 disabled as well). Cheers Jakub
  99764
July 5, 2017 13:34 weltling@outlook.de (Anatol Belski)
Hi Jakub,

> -----Original Message----- > From: jakub.php@gmail.com [mailto:jakub.php@gmail.com] On Behalf Of Jakub > Zelenka > Sent: Wednesday, July 5, 2017 3:24 PM > To: Niklas Keller <me@kelunik.com> > Cc: Anatol Belski <weltling@outlook.de>; Sara Golemon <pollita@php.net>; PHP > Internals <internals@lists.php.net> > Subject: Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates > > Hi, > > > On Tue, Jul 4, 2017 at 10:13 PM, Niklas Keller <me@kelunik.com > <mailto:me@kelunik.com> > wrote: > > > > > But the RFC is what you wrote about some days ago. Anything I > told is based on the RFC and the previous conversations. My understanding was, > that you were intended to push the exact RFC to vote. If you tell now there's no > approach and the RFC has to be ignored, then it doesn't help. If there's another > approach, so please present it. > > > Nobody wants to backport OpenSSL's implementation, so I don't see the > viability of supporting `auth_level`. > > > Backporting auth_level would be overkill but we could add a sig_level as I said > previously. It would simplify many things in the future and address exactly the > issue. Setting explicit options named by algorithm is not flexible and after couple > of years it will be just an ugly unused leftover from past... > > > > I've outlined my current suggestion several mails ago: > > ----- > > 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. > ----- > > > > I don't like adding new INI in general. It won't really help because people won't > usually set it and changing behavior in such way is not good IMHO. > > To sum it up I'd really prefer solution based on security level (in this case just a > sig_level part of it) and have it just as a context option which could be > backported in the following way: > > 7.0 - default to 0 (the same behavior as now to be safe) > 7.1 - default to 1 (80 bits of security and more - disable md5 as it shouldn't break > too many apps and at least protect against md5 signed certs). > 7.2 - default to 2 (SHA-1 disabled as well). > Do you think it were possible to get in time with an implementation, if there's an agreement? As Sara is willing to accept a fix to this even later in the cycle, and that could be a good chance to align all the branches. As for me, this approach sounds feasible from both BC and functionality POV, except one detail - say if in 7.2 the level is for some reason have to be set to 0 because an app requires it, it should be possible at least for some time.
Thanks Anatol
  99769
July 5, 2017 16:14 bukka@php.net (Jakub Zelenka)
On Wed, Jul 5, 2017 at 2:34 PM, Anatol Belski <weltling@outlook.de> wrote:

> Hi Jakub, > > > -----Original Message----- > > From: jakub.php@gmail.com [mailto:jakub.php@gmail.com] On Behalf Of > Jakub > > Zelenka > > Sent: Wednesday, July 5, 2017 3:24 PM > > To: Niklas Keller <me@kelunik.com> > > Cc: Anatol Belski <weltling@outlook.de>; Sara Golemon <pollita@php.net>; > PHP > > Internals <internals@lists.php.net> > > Subject: Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates > > > > Hi, > > > > > > On Tue, Jul 4, 2017 at 10:13 PM, Niklas Keller <me@kelunik.com > > <mailto:me@kelunik.com> > wrote: > > > > > > > > > > But the RFC is what you wrote about some days ago. > Anything I > > told is based on the RFC and the previous conversations. My > understanding was, > > that you were intended to push the exact RFC to vote. If you tell now > there's no > > approach and the RFC has to be ignored, then it doesn't help. If there's > another > > approach, so please present it. > > > > > > Nobody wants to backport OpenSSL's implementation, so I don't see > the > > viability of supporting `auth_level`. > > > > > > Backporting auth_level would be overkill but we could add a sig_level as > I said > > previously. It would simplify many things in the future and address > exactly the > > issue. Setting explicit options named by algorithm is not flexible and > after couple > > of years it will be just an ugly unused leftover from past... > > > > > > > > I've outlined my current suggestion several mails ago: > > > > ----- > > > > 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. > > ----- > > > > > > > > I don't like adding new INI in general. It won't really help because > people won't > > usually set it and changing behavior in such way is not good IMHO. > > > > To sum it up I'd really prefer solution based on security level (in this > case just a > > sig_level part of it) and have it just as a context option which could be > > backported in the following way: > > > > 7.0 - default to 0 (the same behavior as now to be safe) > > 7.1 - default to 1 (80 bits of security and more - disable md5 as it > shouldn't break > > too many apps and at least protect against md5 signed certs). > > 7.2 - default to 2 (SHA-1 disabled as well). > > > Do you think it were possible to get in time with an implementation, if > there's an agreement?
Yep it would be a small patch so I don't see a problem with that..
> As Sara is willing to accept a fix to this even later in the cycle, and > that could be a good chance to align all the branches. As for me, this > approach sounds feasible from both BC and functionality POV, except one > detail - say if in 7.2 the level is for some reason have to be set to 0 > because an app requires it, it should be possible at least for some time. > > It would be a context option so app could change it when creating stream
context. I think there is no need to have a global option as this should be specific to stream. Cheers Jakub
  99737
July 4, 2017 11:11 weltling@outlook.de (Anatol Belski)
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
  99745
July 4, 2017 18:25 me@kelunik.com (Niklas Keller)
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
  99722
July 3, 2017 17:21 pollita@php.net (Sara Golemon)
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.
  99738
July 4, 2017 11:18 weltling@outlook.de (Anatol Belski)
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
  99253
May 30, 2017 05:51 me@kelunik.com (Niklas Keller)
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... >
  99283
May 30, 2017 20:11 bukka@php.net (Jakub Zelenka)
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