Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:99765 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 59014 invoked from network); 5 Jul 2017 14:39:10 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 5 Jul 2017 14:39:10 -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.163 cause and error) X-PHP-List-Original-Sender: me@kelunik.com X-Host-Fingerprint: 81.169.146.163 mo4-p00-ob.smtp.rzone.de Received: from [81.169.146.163] ([81.169.146.163:15959] helo=mo4-p00-ob.smtp.rzone.de) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 67/DD-15131-60AFC595 for ; Wed, 05 Jul 2017 10:39:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1499265540; l=6591; s=domk; d=kelunik.com; h=Content-Type:Cc:To:Subject:Date:From:References:In-Reply-To: MIME-Version; bh=qZGDZyrzdgzXo2QAD0nxan5DgzxKkQuydjbI7XjNFrM=; b=oL0hdJL+ebQTTIMQZruYU0uVf7DzItdmtoJrywymrjtngGsTydv/dSyXp4+NSQ+yxO 7+uWKIkhz5AJiXjcpHeFt49iR0JDGJMbDSnNVYYNBG4AeyXXlwPhMB9QGj4OdBIfQ8gL Q7JW1ZfpTICyQ+eWSySfI1lMJBx26v9osAhWA= X-RZG-AUTH: :IWkkfkWkbvHsXQGmRYmUo9mls2vWuiu+7SLDup6E67mzuoNHBqX83Q== X-RZG-CLASS-ID: mo00 Received: by mail-oi0-f44.google.com with SMTP id 191so101171513oii.2 for ; Wed, 05 Jul 2017 07:38:59 -0700 (PDT) X-Gm-Message-State: AKS2vOzSjvphcx9H6+3wwMqkQVxvGnoYi22lHxKyvHUfDxN+fe3D4qaG RmjWJya2TxVQ9SjgVX9twjoq/IHsgw== X-Received: by 10.202.7.70 with SMTP id 67mr24116037oih.184.1499265539004; Wed, 05 Jul 2017 07:38:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.154.177 with HTTP; Wed, 5 Jul 2017 07:38:58 -0700 (PDT) In-Reply-To: References: Date: Wed, 5 Jul 2017 16:38:58 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Anatol Belski Cc: Sara Golemon , Jakub Zelenka , PHP Internals Content-Type: multipart/alternative; boundary="94eb2c13e51ee0661f055392f575" Subject: Re: [PHP-DEV] Re: [RFC] Distrust SHA-1 Certificates From: me@kelunik.com (Niklas Keller) --94eb2c13e51ee0661f055392f575 Content-Type: text/plain; charset="UTF-8" > > 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 --94eb2c13e51ee0661f055392f575--