Welcome! Log In Create A New Profile

Advanced

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

Posted by Niklas Keller 
Niklas Keller
Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
July 04, 2017 08:30PM
2017-07-04 13:33 GMT+02:00 Anatol Belski <[email protected]>:

> Hi,
>
> > -----Original Message-----
> > From: Niklas Keller [mailto:[email protected]]
> > Sent: Monday, July 3, 2017 8:12 PM
> > To: Sara Golemon <[email protected]>
> > Cc: Anatol Belski <[email protected]>; Jakub Zelenka <[email protected]>;
> PHP
> > Internals <[email protected]>
> > Subject: Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
> >
> > 2017-07-03 19:24 GMT+02:00 Sara Golemon <[email protected]
> > <mailto:[email protected]> >:
> >
> >
> > On Mon, Jul 3, 2017 at 1:12 PM, Niklas Keller <[email protected]
> > <mailto:[email protected]> > 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
Niklas Keller
Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
July 04, 2017 08:30PM
2017-07-04 13:11 GMT+02:00 Anatol Belski <[email protected]>:

> Hi Niklas,
>
> > -----Original Message-----
> > From: Niklas Keller [mailto:[email protected]]
> > Sent: Monday, July 3, 2017 7:13 PM
> > To: Anatol Belski <[email protected]>; Sara Golemon <[email protected]>
> > Cc: Jakub Zelenka <[email protected]>; 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
Anatol Belski
RE: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
July 04, 2017 10:30PM
> -----Original Message-----
> From: Niklas Keller [mailto:[email protected]]
> Sent: Tuesday, July 4, 2017 8:21 PM
> To: Anatol Belski <[email protected]>
> Cc: Sara Golemon <[email protected]>; Jakub Zelenka <[email protected]>; PHP
> Internals <[email protected]>
> Subject: Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
>
> 2017-07-04 13:33 GMT+02:00 Anatol Belski <[email protected]
> <mailto:[email protected]> >:
>
> 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
Niklas Keller
Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
July 04, 2017 11:20PM
>
> 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
Anatol Belski
RE: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
July 04, 2017 11:40PM
> -----Original Message-----
> From: Niklas Keller [mailto:[email protected]]
> Sent: Tuesday, July 4, 2017 11:14 PM
> To: Anatol Belski <[email protected]>
> Cc: Sara Golemon <[email protected]>; Jakub Zelenka <[email protected]>; PHP
> Internals <[email protected]>
> 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.
Niklas Keller
Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
July 05, 2017 09:50AM
>
> > 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
Jakub Zelenka
Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
July 05, 2017 03:30PM
Hi,

On Tue, Jul 4, 2017 at 10:13 PM, Niklas Keller <[email protected]> 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
Anatol Belski
RE: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
July 05, 2017 03:40PM
Hi,

> -----Original Message-----
> From: Niklas Keller [mailto:[email protected]]
> Sent: Wednesday, July 5, 2017 9:43 AM
> To: Anatol Belski <[email protected]>
> Cc: Sara Golemon <[email protected]>; Jakub Zelenka <[email protected]>; PHP
> Internals <[email protected]>
> 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
Anatol Belski
RE: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
July 05, 2017 03:40PM
Hi Davey,

> -----Original Message-----
> From: me@daveyshafik.com [mailto:[email protected]] On Behalf Of Davey
> Shafik
> Sent: Tuesday, July 4, 2017 8:53 AM
> To: Niklas Keller <[email protected]>
> Cc: Sara Golemon <[email protected]>; Anatol Belski <[email protected]>;
> Jakub Zelenka <[email protected]>; PHP Internals <[email protected]>
> 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
Anatol Belski
RE: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
July 05, 2017 03:40PM
Hi Jakub,

> -----Original Message-----
> From: jakub.php@gmail.com [mailto:[email protected]] On Behalf Of Jakub
> Zelenka
> Sent: Wednesday, July 5, 2017 3:24 PM
> To: Niklas Keller <[email protected]>
> Cc: Anatol Belski <[email protected]>; Sara Golemon <[email protected]>; PHP
> Internals <[email protected]>
> Subject: Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
>
> Hi,
>
>
> On Tue, Jul 4, 2017 at 10:13 PM, Niklas Keller <[email protected]
> <mailto:[email protected]> > 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
Niklas Keller
Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
July 05, 2017 04:50PM
>
> 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
Jakub Zelenka
Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
July 05, 2017 06:20PM
On Wed, Jul 5, 2017 at 2:34 PM, Anatol Belski <[email protected]> wrote:

> Hi Jakub,
>
> > -----Original Message-----
> > From: jakub.php@gmail.com [mailto:[email protected]] On Behalf Of
> Jakub
> > Zelenka
> > Sent: Wednesday, July 5, 2017 3:24 PM
> > To: Niklas Keller <[email protected]>
> > Cc: Anatol Belski <[email protected]>; Sara Golemon <[email protected]>;
> PHP
> > Internals <[email protected]>
> > Subject: Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
> >
> > Hi,
> >
> >
> > On Tue, Jul 4, 2017 at 10:13 PM, Niklas Keller <[email protected]
> > <mailto:[email protected]> > 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
Anatol Belski
RE: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
July 06, 2017 05:00PM
Morning, guys,

> -----Original Message-----
> From: Niklas Keller [mailto:[email protected]]
> Sent: Wednesday, July 5, 2017 4:39 PM
> To: Anatol Belski <[email protected]>
> Cc: Sara Golemon <[email protected]>; Jakub Zelenka <[email protected]>; PHP
> Internals <[email protected]>
> 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
Anatol Belski
RE: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
July 10, 2017 11:00PM
Hi,

> -----Original Message-----
> From: Anatol Belski [mailto:[email protected]]
> Sent: Thursday, July 6, 2017 4:52 PM
> To: Niklas Keller <[email protected]>
> Cc: Sara Golemon <[email protected]>; Jakub Zelenka <[email protected]>; PHP
> Internals <[email protected]>
> Subject: RE: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
>
> Morning, guys,
>
> > -----Original Message-----
> > From: Niklas Keller [mailto:[email protected]]
> > Sent: Wednesday, July 5, 2017 4:39 PM
> > To: Anatol Belski <[email protected]>
> > Cc: Sara Golemon <[email protected]>; Jakub Zelenka <[email protected]>; PHP
> > Internals <[email protected]>
> > 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
Jakub Zelenka
Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
July 11, 2017 06:40PM
On Mon, Jul 10, 2017 at 9:54 PM, Anatol Belski <[email protected]> wrote:

> Hi,
>
> > -----Original Message-----
> > From: Anatol Belski [mailto:[email protected]]
> > Sent: Thursday, July 6, 2017 4:52 PM
> > To: Niklas Keller <[email protected]>
> > Cc: Sara Golemon <[email protected]>; Jakub Zelenka <[email protected]>; PHP
> > Internals <[email protected]>
> > Subject: RE: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
> >
> > Morning, guys,
> >
> > > -----Original Message-----
> > > From: Niklas Keller [mailto:[email protected]]
> > > Sent: Wednesday, July 5, 2017 4:39 PM
> > > To: Anatol Belski <[email protected]>
> > > Cc: Sara Golemon <[email protected]>; Jakub Zelenka <[email protected]>; PHP
> > > Internals <[email protected]>
> > > 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
Niklas Keller
Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
July 11, 2017 07:20PM
2017-07-11 18:34 GMT+02:00 Jakub Zelenka <[email protected]>:

> On Mon, Jul 10, 2017 at 9:54 PM, Anatol Belski <[email protected]>
> wrote:
>
> > Hi,
> >
> > > -----Original Message-----
> > > From: Anatol Belski [mailto:[email protected]]
> > > Sent: Thursday, July 6, 2017 4:52 PM
> > > To: Niklas Keller <[email protected]>
> > > Cc: Sara Golemon <[email protected]>; Jakub Zelenka <[email protected]>; PHP
> > > Internals <[email protected]>
> > > Subject: RE: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
> > >
> > > Morning, guys,
> > >
> > > > -----Original Message-----
> > > > From: Niklas Keller [mailto:[email protected]]
> > > > Sent: Wednesday, July 5, 2017 4:39 PM
> > > > To: Anatol Belski <[email protected]>
> > > > Cc: Sara Golemon <[email protected]>; Jakub Zelenka <[email protected]>;
> PHP
> > > > Internals <[email protected]>
> > > > 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
Anatol Belski
RE: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
July 13, 2017 01:30PM
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
Niklas Keller
Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
July 17, 2017 10:10AM
>
> 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
Jakub Zelenka
Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
July 17, 2017 07:00PM
Hey,

On Mon, Jul 17, 2017 at 8:58 AM, Niklas Keller <[email protected]> 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
Niklas Keller
Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates
November 11, 2017 10:50AM
>
> 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
Sorry, only registered users may post in this forum.

Click here to login