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 05:11:23 +0100 Message-ID: References: <87fu1apchn.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000002d465a056f83b2bb" X-Trace: blaine.gmane.org 1529986212 516 195.159.176.226 (26 Jun 2018 04:10:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 26 Jun 2018 04:10:12 +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 06:10:08 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 1fXfIr-0008RW-2Z for geb-bug-gnu-emacs@m.gmane.org; Tue, 26 Jun 2018 06:10:05 +0200 Original-Received: from localhost ([::1]:50475 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fXfKy-00076Y-3p for geb-bug-gnu-emacs@m.gmane.org; Tue, 26 Jun 2018 00:12:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48202) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fXfKo-00076Q-8d for bug-gnu-emacs@gnu.org; Tue, 26 Jun 2018 00:12:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fXfKk-0006So-Mj for bug-gnu-emacs@gnu.org; Tue, 26 Jun 2018 00:12:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:55863) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fXfKk-0006Rj-Ez for bug-gnu-emacs@gnu.org; Tue, 26 Jun 2018 00:12:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1fXfKk-0006eU-0Q for bug-gnu-emacs@gnu.org; Tue, 26 Jun 2018 00:12: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 04:12:01 +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.152998631925561 (code B ref 31946); Tue, 26 Jun 2018 04:12:01 +0000 Original-Received: (at 31946) by debbugs.gnu.org; 26 Jun 2018 04:11:59 +0000 Original-Received: from localhost ([127.0.0.1]:35527 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fXfKd-0006eA-Ul for submit@debbugs.gnu.org; Tue, 26 Jun 2018 00:11:59 -0400 Original-Received: from mail-io0-f169.google.com ([209.85.223.169]:40996) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fXfKX-0006do-Uz for 31946@debbugs.gnu.org; Tue, 26 Jun 2018 00:11:53 -0400 Original-Received: by mail-io0-f169.google.com with SMTP id k16-v6so11867765ioa.8 for <31946@debbugs.gnu.org>; Mon, 25 Jun 2018 21:11:49 -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=p/p5g97GQcco8gmztIORwzfgBvfQwu0zIXwcHMCmLCc=; b=NiXPlCePpIfeuosHqEjxfz39VLijBnIq0EtuGD+DjjBR2V8xYCLp/4S6EtfCvCFUE9 zpuej0QPxALor1KFWNoTtORid60yFwTp7GOk/hIHUbb9ZRBqglZdZhVdwI8L+MFsweFq 2YiJEHZ/xH3rlyPx0AOn/lGz9Y91t0og14rDVO52mmg54UaOgca9EuzuXApeEWxIC0aQ 4xzJ7RH7lzqYk4OoFX9ODUmuzdVIj2xjHnbxR+u8yXelVFmSJeQhUFgv0aU3NWxIghi8 WZxauOI9IbxHT9JT2bQxMpYA5I+midx9E4gimX5L1b3JJbdMpSazfNwDXm9CPcii8ByN eHPA== 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=p/p5g97GQcco8gmztIORwzfgBvfQwu0zIXwcHMCmLCc=; b=r7ChDOjh+G9dAPyvy3cA92kdj4aq32jmw1Kr6RO9PT6amhsNtJS0CjWjABbQwwXf42 MmzM8canHa9El+Ts2YPjVgfi4txVhIihStiroHZeu4TZqElffq4KYqWLnlOZ9X0OZ6GM wDMAGxnyxsSIOTTwgB0o4CDl++tXLwhR8F7Kl0PXvTs7MAMH4UAaM50caszkoabuxmWp 9/yZHgmyBQh1fRs9qk03sQ90SuptHq4nHCOf+sEfCRxuzJ9q4Wq8bv0bUkQehuKrzvxW WOij8K+G/WtnqWRfent7BQ15jcJdAk01GmKQxcmgVK7qQo8MomlKCHZj+ka4g+0gjWF5 oTMA== X-Gm-Message-State: APt69E2iVnn73IJcuwsNxc2eea6CYXOabz15s9x2NWKYqBqwdDY7UrHQ 87NCe615Sp/8Yo4Zi/frM9AGykkO4aAbh9CvN4U= X-Google-Smtp-Source: AAOMgpfAVCGQu2CKVz8xOU2S/F7ojh98xmNPY0n0qhobiH2U2AnCpj/+NpFcmV2YOV+OadBqa252araEHezuaGIxtPQ= X-Received: by 2002:a5e:9812:: with SMTP id s18-v6mr4970080ioj.117.1529986304261; Mon, 25 Jun 2018 21:11:44 -0700 (PDT) Original-Received: by 2002:a02:985d:0:0:0:0:0 with HTTP; Mon, 25 Jun 2018 21:11:23 -0700 (PDT) In-Reply-To: <87fu1apchn.fsf@gmail.com> 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:147829 Archived-At: --0000000000002d465a056f83b2bb Content-Type: text/plain; charset="UTF-8" `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- sizes-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 > > > --0000000000002d465a056f83b2bb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
`dh-composite` can be mitigated by using the "NO= RMAL:%PROFILE_MEDIUM" priority string[1], "NORMAL:%PROFILE_HIGH&q= uot; [2] will pass all 26 badssl test while still allowing connection to EL= PA/MELPA without even supplying CRL files (GnuTLS already does OCSP staplin= g verifcation transparently, and Emacs is using it already minus surfacing = `GNUTLS_CERT_MISSING_OCSP_STATUS` when it fails). The exact meaning these l= evels appears to be spread out among different tables in ENISA's Algori= thms, 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 o= f having users to edit an alist like Lars has done in commit 6584bc67, we c= ould:

1. Append `network-security-level` to `gnutl= s-algorithm-priority`, i.e. `network-security-level` will be a list of pred= efined symbols that will be mapped to GnuTLS's `%PROFILE_*` strings, an= d append to it when setting up `gnutls-boot-parameters`.
2. Forge= t about letting users decide whether they want to accept problematic certs = or not, no modern browsers does it anymore. Doing network security checks i= n 2 different places also introduces impedance mismatch. Specifically, GnuT= LS 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 impleme= nted and reinvent all the wheels in LISP (do you really want to reenable SS= L3?). This is insane from both a security and performance perspective, as w= e don't have reliable NETSEC resources to respond to any security issue= s that we may introduce during the process. Even if we do, there's a la= rger 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`, `gnutl= s-key-exchange` etc, see [1] for the table.
4. Normally, the fine= tuning defcustoms in 3) will be nil, in which case `gnutls-algorithm-prior= ity` takes precedence, otherwise they are combined into a final priority st= ring supplied to `gnutls-boot-parameters`.
5. Merge nsm into the = gnutls group. No more distinction between interactive and non-interactive s= essions due to 2).

References:
<= a href=3D"https://gnutls.org/manual/html_node/Priority-Strings.html" target= =3D"_blank">[1]: https://gnutls.org/manual/html_node/Priority-Strings.= html

On Tue, Jun 26, 2018 at 2:23 AM, = Noam Postavsky <npostavs@gmail.com> wrote:
Lars Ingebrigtsen <l= arsi@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



--0000000000002d465a056f83b2bb--