2017-07-11 18:34 GMT+02:00 Jakub Zelenka <bu...@php.net>: > 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
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
