Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:99838 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 90510 invoked from network); 11 Jul 2017 17:12:05 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 11 Jul 2017 17:12:05 -0000 Authentication-Results: pb1.pair.com header.from=me@kelunik.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=me@kelunik.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain kelunik.com from 81.169.146.220 cause and error) X-PHP-List-Original-Sender: me@kelunik.com X-Host-Fingerprint: 81.169.146.220 mo4-p00-ob.smtp.rzone.de Received: from [81.169.146.220] ([81.169.146.220:31601] helo=mo4-p00-ob.smtp.rzone.de) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 40/29-47109-3E605695 for ; Tue, 11 Jul 2017 13:12:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1499793120; l=13378; s=domk; d=kelunik.com; h=Content-Type:Cc:To:Subject:Date:From:References:In-Reply-To: MIME-Version; bh=tW68jC4zNHRtn+DQTsYWRqfXkEHC4GxJPQ1/95Hh/0o=; b=b20mCYIAz4RuxYnBQckSuv+u/7L77jPHfxnTbYftzaZv9q5ASPIRf0uAeUyr5yH4eh OwxF7dWlKIYRtUnvvujnwaXvnMe/wuFiVNjNuv5GB2io8SnFHXuYnIE3BfDjxZV4EhY1 i9Lh9kPAcviJfh/B7AOGF0lt5a5GVrByJ1fuY= X-RZG-AUTH: :IWkkfkWkbvHsXQGmRYmUo9mls2vWuiu+7SLDup6E67mzuoNHBqX93Q== X-RZG-CLASS-ID: mo00 Received: by mail-oi0-f45.google.com with SMTP id x187so5580093oig.3 for ; Tue, 11 Jul 2017 10:12:00 -0700 (PDT) X-Gm-Message-State: AIVw111HSJQXeiebYuWVd4RISrYJC9Prd5GcKD0Z7VLiSKjmeSifJtQB XMu8tX8r1znH2eE9ycQkuqgjsby3oQ== X-Received: by 10.202.1.209 with SMTP id 200mr785460oib.110.1499793119575; Tue, 11 Jul 2017 10:11:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.154.177 with HTTP; Tue, 11 Jul 2017 10:11:58 -0700 (PDT) In-Reply-To: References: Date: Tue, 11 Jul 2017 19:11:58 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Jakub Zelenka Cc: Anatol Belski , Sara Golemon , PHP Internals Content-Type: multipart/alternative; boundary="001a1137be7821088f05540dccbf" Subject: Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates From: me@kelunik.com (Niklas Keller) --001a1137be7821088f05540dccbf Content-Type: text/plain; charset="UTF-8" 2017-07-11 18:34 GMT+02:00 Jakub Zelenka : > On Mon, Jul 10, 2017 at 9:54 PM, Anatol Belski > wrote: > > > Hi, > > > > > -----Original Message----- > > > From: Anatol Belski [mailto:weltling@outlook.de] > > > Sent: Thursday, July 6, 2017 4:52 PM > > > To: Niklas Keller > > > Cc: Sara Golemon ; Jakub Zelenka ; PHP > > > Internals > > > Subject: RE: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates > > > > > > Morning, guys, > > > > > > > -----Original Message----- > > > > From: Niklas Keller [mailto:me@kelunik.com] > > > > Sent: Wednesday, July 5, 2017 4:39 PM > > > > To: Anatol Belski > > > > Cc: Sara Golemon ; Jakub Zelenka ; > PHP > > > > Internals > > > > 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 --001a1137be7821088f05540dccbf--