From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Jimmy Yuen Ho Wong Newsgroups: gmane.emacs.bugs Subject: bug#31946: 27.0.50; The NSM should warn about more TLS problems Date: Tue, 26 Jun 2018 07:26:20 +0100 Message-ID: References: <87fu1apchn.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000c62c2f056f8594ae" X-Trace: blaine.gmane.org 1529994314 30966 195.159.176.226 (26 Jun 2018 06:25:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 26 Jun 2018 06:25:14 +0000 (UTC) Cc: Lars Ingebrigtsen , 31946@debbugs.gnu.org To: Noam Postavsky Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jun 26 08:25:10 2018 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fXhPZ-0007y9-Qy for geb-bug-gnu-emacs@m.gmane.org; Tue, 26 Jun 2018 08:25:10 +0200 Original-Received: from localhost ([::1]:50758 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fXhRg-0003N7-Vd for geb-bug-gnu-emacs@m.gmane.org; Tue, 26 Jun 2018 02:27:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36206) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fXhRS-0003N0-Io for bug-gnu-emacs@gnu.org; Tue, 26 Jun 2018 02:27:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fXhRO-0000bq-Uq for bug-gnu-emacs@gnu.org; Tue, 26 Jun 2018 02:27:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:55898) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fXhRO-0000b9-Pj for bug-gnu-emacs@gnu.org; Tue, 26 Jun 2018 02:27:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fXhRO-0001Ux-Ax for bug-gnu-emacs@gnu.org; Tue, 26 Jun 2018 02:27:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Jimmy Yuen Ho Wong Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 26 Jun 2018 06:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 31946 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: security Original-Received: via spool by 31946-submit@debbugs.gnu.org id=B31946.15299944155747 (code B ref 31946); Tue, 26 Jun 2018 06:27:02 +0000 Original-Received: (at 31946) by debbugs.gnu.org; 26 Jun 2018 06:26:55 +0000 Original-Received: from localhost ([127.0.0.1]:35562 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fXhRE-0001UY-9E for submit@debbugs.gnu.org; Tue, 26 Jun 2018 02:26:55 -0400 Original-Received: from mail-it0-f45.google.com ([209.85.214.45]:40822) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fXhR8-0001UF-Je for 31946@debbugs.gnu.org; Tue, 26 Jun 2018 02:26:50 -0400 Original-Received: by mail-it0-f45.google.com with SMTP id 188-v6so627843ita.5 for <31946@debbugs.gnu.org>; Mon, 25 Jun 2018 23:26:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GNug9nICkp3Lw/X230g/IyuaWvNTzgN6kSAIOwD27bM=; b=EBfpZKS9p5YgLhfnr9+D3wcY/+3ZnhcJGvFCGXI6RkiSpzZY9pQ2b6T6+tc8Od+pSn xkunK7zEHcw+3y2lLlkQbgk/eEXhMC0dtlC4PDPDiDYkNsVmVJCl++pes/d8m8OkZPyM WK1lighmN0oiHCMx6uReZ9EdYaR/FEyaTXBdx7WbSCHLP/hW5FdBAtqrLGOJrWVzhr11 Enlm5TBt983k0oFGhYCk2FlSuhc+QqoHP5JfaIordPPKajniDvj5MMFlmSg55+asYOrl zPWBrHkru0EDoBLg9CGybr31kI8xMWNXqOvTEufBydojdDVv+kQapXCfKmiQlGG3dsGl GwSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GNug9nICkp3Lw/X230g/IyuaWvNTzgN6kSAIOwD27bM=; b=gHKzzayGhSBP49Bp2EVzYUsiGgvFmV7qyRRbYzHBStAGeoLQ9uVz5Y49HgZhHncpqy T67skRUtcUBKu2DLOrRLyuISVMGQ/3OlDiiWt0oWaThlf13FlWN4Dg5auZdBsrZjfCIF /3nm6glzA3dJed1Acdwo0LsU4hhUm4vm2J8ZdxprOyU0Vp35BRgne+BYLq6ATq8wfHU3 WJ3KsCqcTfIWkYYkoy2RG9505v3+ngfWxNXIhdWykH6B0iRGEEsFFO80tfgR2Lw9/ceO VpKu65usQ41PBf5e6r8rAr+rw6mYjeeytl4x0i96TO/w+lUjWjT5lSn9v/je9xDxs/Kp 1vDA== X-Gm-Message-State: APt69E0X8A3xLF+irYAgPEgEVbqu0zHU+Os53yBiGPC2i5LZN3dcuFTb Ub55KfFJYjAHB25uq25mB16UOyB1ZDx/RRcbjgI= X-Google-Smtp-Source: ADUXVKLkFHHPkOGwABCRByJvqxK/nul3pWywW9D+gpSr6i/QWGzZIiy3qICdocsWxmNPfaCQxoITVF2Kx+E8beBsxik= X-Received: by 2002:a24:7311:: with SMTP id y17-v6mr411767itb.105.1529994400900; Mon, 25 Jun 2018 23:26:40 -0700 (PDT) Original-Received: by 2002:a02:985d:0:0:0:0:0 with HTTP; Mon, 25 Jun 2018 23:26:20 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:147830 Archived-At: --000000000000c62c2f056f8594ae Content-Type: text/plain; charset="UTF-8" Sorry I was confused in my last reply about modern browsers not allowing you to accept certs. Chrome just hides that functionality really well, so forget about my proposal earlier. (one should not reply to emails at 5 in the morning) Here's my new proposal: 1. Forget about defining what tests belongs in what levels, there should just be one level which is the default sets of tests, let's call this coarse grain setting. 2. Fine grain settings should only allow you to **add** to the default list of checks, so it will be a defcustom of an alist (there's prior art of this), let's call this `nsm-additional-checks` 3. We can predefine a bunch of check functions that users can add to `nsm-additional-checks` without having to write their own. 4. For dh-small-subgroup and dh-composite, the only way to check this in LISP seems to be to supply `:min-prime-bits 2048` to `gnutls-boot-parameters`. In which case GnuTLS will fail with fatal alert for both counts. A user will not be able to accept dh-small-subgroup and dh-composite certs if checks for them are enabled. This is fine, as a user is not able to accept RC4 certs via NSM now, browsers also do it this way. On Tue, Jun 26, 2018 at 5:11 AM, Jimmy Yuen Ho Wong wrote: > `dh-composite` can be mitigated by using the "NORMAL:%PROFILE_MEDIUM" > priority string[1], "NORMAL:%PROFILE_HIGH" [2] will pass all 26 badssl test > while still allowing connection to ELPA/MELPA without even supplying CRL > files (GnuTLS already does OCSP stapling verifcation transparently, and > Emacs is using it already minus surfacing `GNUTLS_CERT_MISSING_OCSP_STATUS` > when it fails). The exact meaning these levels appears to be spread out > among different tables in ENISA's Algorithms, Key Sizes and Parameters > Report - 2013 [3]. > > As a possible way to avoid confusion, I would suggest we consolidate the 2 > different meaning of profiles (NSM and GnuTLS) into GnuTLS's. Instead of > having users to edit an alist like Lars has done in commit 6584bc67, we > could: > > 1. Append `network-security-level` to `gnutls-algorithm-priority`, i.e. > `network-security-level` will be a list of predefined symbols that will be > mapped to GnuTLS's `%PROFILE_*` strings, and append to it when setting up > `gnutls-boot-parameters`. > 2. Forget about letting users decide whether they want to accept > problematic certs or not, no modern browsers does it anymore. Doing network > security checks in 2 different places also introduces impedance mismatch. > Specifically, GnuTLS by default disables a number of cyphers and hashes. > The only way to stop it from generating fatal alerts is to enable > everything GnuTLS has implemented and reinvent all the wheels in LISP (do > you really want to reenable SSL3?). This is insane from both a security and > performance perspective, as we don't have reliable NETSEC resources to > respond to any security issues that we may introduce during the process. > Even if we do, there's a larger problem of Emacs's release process. > 3. To solve the problem of letting users fine tune the client's acceptable > cyphersuite, MACs and whatnot for emergencies out of Emacs' release cycles, > let's introduce a bunch of new defcustoms such as `gnutls-cyphersuite`, > `gnutls-key-exchange` etc, see [1] for the table. > 4. Normally, the fine tuning defcustoms in 3) will be nil, in which case > `gnutls-algorithm-priority` takes precedence, otherwise they are combined > into a final priority string supplied to `gnutls-boot-parameters`. > 5. Merge nsm into the gnutls group. No more distinction between > interactive and non-interactive sessions due to 2). > > References: > [1]: https://gnutls.org/manual/html_node/Priority-Strings.html > > [2]: https://gnutls.org/manual/html_node/Selecting-cryptographic- > key-sizes.html#tab_003akey_002dsizes > > [3]: https://www.enisa.europa.eu/publications/algorithms-key-size > s-and-parameters-report > > > > On Tue, Jun 26, 2018 at 2:23 AM, Noam Postavsky > wrote: > >> Lars Ingebrigtsen writes: >> >> > There are also more protocol stuff we should warn about on various >> > levels. These should be on `high': >> >> >> "https://dh-small-subgroup.badssl.com/" ;; fail >> >> "https://dh-composite.badssl.com/" ;; fail >> >> So these ones seem kind of problematic, as alluded to on emacs-devel. >> It doesn't look like gnutls has an API to get or check the value of the >> DH primes (calc-prime-test bails out when given a 1024 bit prime, so we >> definitely need library support for this). >> >> https://lists.gnu.org/archive/html/emacs-devel/2018-06/msg00805.html >> https://lists.gnu.org/archive/html/emacs-devel/2018-06/msg00807.html >> >> >> > --000000000000c62c2f056f8594ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry I was confused in my last reply about modern br= owsers not allowing you to accept certs. Chrome just hides that functionali= ty really well, so forget about my proposal earlier. (one should not reply= to emails at 5 in the morning) Here's my new proposal:
<= br>
1. Forget about defining what tests belongs in what levels, t= here should just be one level which is the default sets of tests, let's= call this coarse grain setting.
2. Fine grain settings shoul= d only allow you to **add** to the default list of checks, so it will be a = defcustom of an alist (there's prior art of this), let's call this = `nsm-additional-checks`
3. We can predefine a bunch of check = functions that users can add to `nsm-additional-checks` without having to w= rite their own.
4. For dh-small-subgroup and dh-composite, th= e only way to check this in LISP seems to be to supply `:min-prime-bits 204= 8` to `gnutls-boot-parameters`. In which case GnuTLS will fail with fatal a= lert for both counts. A user will not be able to accept dh-small-subgroup a= nd dh-composite certs if checks for them are enabled. This is fine, as a us= er is not able to accept RC4 certs via NSM now, browsers also do it this wa= y.

On Tu= e, Jun 26, 2018 at 5:11 AM, Jimmy Yuen Ho Wong <wyuenho@gmail.com><= /span> wrote:
`dh-c= omposite` can be mitigated by using the "NORMAL:%PROFILE_MEDIUM" = priority string[1], "NORMAL:%PROFILE_HIGH" [2] will pass all 26 b= adssl test while still allowing connection to ELPA/MELPA without even suppl= ying CRL files (GnuTLS already does OCSP stapling verifcation transparently= , and Emacs is using it already minus surfacing `GNUTLS_CERT_MISSING_OCSP_S= TATUS` when it fails). The exact meaning these levels appears to be sp= read out among different tables in ENISA's Algorithms, Key Sizes and Pa= rameters Report - 2013 [3].

As a possible way to a= void confusion, I would suggest we consolidate the 2 different meaning of p= rofiles (NSM and GnuTLS) into GnuTLS's. Instead of having users to edit= an alist like Lars has done in commit 6584bc67, we could:

1. Append `network-security-level` to `gnutls-algorithm-priority`,= i.e. `network-security-level` will be a list of predefined symbols that wi= ll be mapped to GnuTLS's `%PROFILE_*` strings, and append to it when se= tting up `gnutls-boot-parameters`.
2. Forget about letting users = decide whether they want to accept problematic certs or not, no modern brow= sers does it anymore. Doing network security checks in 2 different places a= lso introduces impedance mismatch. Specifically, GnuTLS by default disables= a number of cyphers and hashes. The only way to stop it from generating fa= tal alerts is to enable everything GnuTLS has implemented and reinvent all = the wheels in LISP (do you really want to reenable SSL3?). This is insane f= rom both a security and performance perspective, as we don't have relia= ble NETSEC resources to respond to any security issues that we may introduc= e during the process. Even if we do, there's a larger problem of Emacs&= #39;s release process.
3. To solve the problem of letting use= rs fine tune the client's acceptable cyphersuite, MACs and whatnot for = emergencies out of Emacs' release cycles, let's introduce a bunch o= f new defcustoms such as `gnutls-cyphersuite`, `gnutls-key-exchange` etc, s= ee [1] for the table.
4. Normally, the fine tuning defcustoms in = 3) will be nil, in which case `gnutls-algorithm-priority` takes precedence,= otherwise they are combined into a final priority string supplied to `gnut= ls-boot-parameters`.
5. Merge nsm into the gnutls group. No more = distinction between interactive and non-interactive sessions due to 2).
=

References:
On Tue, Jun 26, 2018 at 2:23 AM, Noam Postavsk= y <npostavs@gmail.com> wrote:
Lars Ingebrigtsen <larsi@gnus.org> writes:

> There are also more protocol stuff we should warn about on various
> levels.=C2=A0 These should be on `high':

>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "= ;https://dh-small-subgroup.badssl.com/"=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ;; fail
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "= ;https://dh-composite.badssl.com/"=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ;; fail

So these ones seem kind of problematic, as alluded to on emacs-devel.
It doesn't look like gnutls has an API to get or check the value of the=
DH primes (calc-prime-test bails out when given a 1024 bit prime, so we
definitely need library support for this).

https://lists.gnu.org/archive/html/emacs-devel/2018-06/msg00805.html
https://lists.gnu.org/archive/html/emacs-devel/2018-06/msg00807.html




--000000000000c62c2f056f8594ae--