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