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
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
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
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
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-certificatesI 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...
2016-11-27 14:09 GMT+01:00 Jakub Zelenka bukka@php.net:
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-certificatesI 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 SHAAh 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
2016-11-27 14:09 GMT+01:00 Jakub Zelenka bukka@php.net:
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-certificatesI 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 SHAAh 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
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
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
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.htmlCheers
Jakub
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-certificatesRegards, Niklas
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ä
2017-05-29 16:03 GMT+02:00 Lauri Kenttä lauri.kentta@gmail.com:
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
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...
2017-05-29 22:00 GMT+02:00 Jakub Zelenka bukka@php.net:
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
2017-05-29 22:00 GMT+02:00 Jakub Zelenka bukka@php.net:
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
2017-05-30 22:26 GMT+02:00 Jakub Zelenka bukka@php.net:
2017-05-29 22:00 GMT+02:00 Jakub Zelenka bukka@php.net:
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
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 Certificates2017-05-30 22:26 GMT+02:00 Jakub Zelenka bukka@php.net:
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
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
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
2017-07-03 19:24 GMT+02:00 Sara Golemon pollita@php.net:
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
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.
2017-07-03 19:24 GMT+02:00 Sara Golemon pollita@php.net:
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
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 CertificatesIt 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
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 Certificates2017-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
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 Certificates2017-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.commailto: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
-----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 Certificates2017-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
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
-----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 CertificatesBut 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 supportingauth_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.
But the RFC is what you wrote about some days ago. Anything I toldis
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 supportingauth_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
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 CertificatesBut the RFC is what you wrote about some days ago. Anything Itold 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 supportingauth_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
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
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 CertificatesOk, 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 completelyNo 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 completelyBoth 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
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 CertificatesMorning, 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 CertificatesOk, so you strive to create a completely new RFC with a solutionbased 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 explicitinsecure_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 completelyNo 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'sdeprecated 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 completelyBoth options do same, but in different manner. Both have advantagesand 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
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 CertificatesMorning, 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 CertificatesOk, so you strive to create a completely new RFC with a solutionbased 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 explicitinsecure_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 completelyNo 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'sdeprecated 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 completelyBoth options do same, but in different manner. Both have advantagesand 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
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 CertificatesMorning, 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 CertificatesOk, so you strive to create a completely new RFC with a solutionbased 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 explicitinsecure_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 completelyNo 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'sdeprecated 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 completelyBoth options do same, but in different manner. Both haveadvantages
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
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
Hi,
After reading related discussion on openssl-users [1], I'm not sosure 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 apractical
certificate forgery based on a collision attack on SHA-1. " The only thing, that makes sense IMHO would be adding support forsetting
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
Hey,
Hi,
After reading related discussion on openssl-users [1], I'm not sosure 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 apractical
certificate forgery based on a collision attack on SHA-1. " The only thing, that makes sense IMHO would be adding support forsetting
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
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.
Unfortunately I forgot about it, but it defaults to 0, which is equivalent
to prior OpenSSL versions. I guess it might make sense for consistency, but
we probably want to raise it to at least "1" in PHP 7.3 or maybe even "2".
OpenSSL's man page explicitly recommends against setting it higher than
"1", but only because of SHA-1, which should be phased out by now.
Regards, Niklas
Hi,
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 supportingauth_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
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 CertificatesHi,
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 Itold 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 supportingauth_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
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 CertificatesHi,
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 seethe
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
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 CertificatesI 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
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 CertificatesI 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 likeRSA 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
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.
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 CertificatesAbout 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
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:
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...
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