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.devel Subject: Re: A couple of questions and concerns about Emacs network security Date: Thu, 5 Jul 2018 16:58:26 +0100 Message-ID: References: <83po0iuhs7.fsf@gnu.org> <83lgb4tg92.fsf@gnu.org> <83efgusvdw.fsf@gnu.org> <20180705115259.4032dbea@jabberwock.cb.piermont.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1530806661 27120 195.159.176.226 (5 Jul 2018 16:04:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 5 Jul 2018 16:04:21 +0000 (UTC) Cc: Lars Ingebrigtsen , Paul Eggert , Emacs-Devel devel , Eli Zaretskii , Noam Postavsky To: "Perry E. Metzger" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 05 18:04:16 2018 Return-path: Envelope-to: ged-emacs-devel@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 1fb6ju-0006sb-HR for ged-emacs-devel@m.gmane.org; Thu, 05 Jul 2018 18:04:14 +0200 Original-Received: from localhost ([::1]:53461 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fb6m1-00013X-Lp for ged-emacs-devel@m.gmane.org; Thu, 05 Jul 2018 12:06:25 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53242) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fb6el-0004ix-MK for emacs-devel@gnu.org; Thu, 05 Jul 2018 11:58:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fb6ei-0005Eh-5r for emacs-devel@gnu.org; Thu, 05 Jul 2018 11:58:55 -0400 Original-Received: from mail-io0-x236.google.com ([2607:f8b0:4001:c06::236]:39228) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fb6ed-0005CX-Th; Thu, 05 Jul 2018 11:58:48 -0400 Original-Received: by mail-io0-x236.google.com with SMTP id e13-v6so8190339iof.6; Thu, 05 Jul 2018 08:58:47 -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=tUamHKy4ehdjzOv8oJeObec2abXKaMwKYK597/vFfek=; b=l8us99XLtuGUWIFiMbgqdouOO2jJy2loyEDmMUG4Ec/cazR8juUoq7bEo7+z7CZQtf o9l3p19nlOqpto9+5tVq8W032VlZjW5biw9upRwLs/vxrggYRWGZLAbokMFKKgfil/LQ guRygWpEK545jC8ZN1JFA4MCWyR1UoSgtNaRO+5fUHcINmN/j0+ue6nEMWNBBw/etBlC jsCGLprjEyVV6n6TcmlvZZgcLOXtRwiAaJwYMdWjAbfnMsD+OdoYjMU5uV9AkurnmSMq eAkC2D8u0hNoysZ1AA+zYUAqLyuFo73Kz7aSEgorKl4Oznd+sQPQ0UJG0CDZ8lPWEpRG cP0g== 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=tUamHKy4ehdjzOv8oJeObec2abXKaMwKYK597/vFfek=; b=pJUK1hOZnlGCby87Bd+IjIXH7KPvsmXio2MDPonHP4wKopiweMk8LKQgagWfm9lZyP GGS6qOGP1HbfDmnNpxEpyoH++lQCtablZtox6fFXoVvtlO+djDzCYk4J3/v5yFKFvem6 HfiJIv3+TFgegLiDRbZJmxQrKzDzm82lPfgc9sV9MMCnSMHg9Jmcnz8xwBOg8IrG89/I 7H16EA+thpNOQrt/7qSEdaTurR7nso8U/Qb2CflWyIa75h4FenIGLgxIjM2Ma6jHUgFa 8Ftu4BLlRIT6h6i6LqEwgHlZ6cv5MZd9sjgdOvr5m8rpFGhDM9XMBnsHfNBBIGQv6gm0 TIcw== X-Gm-Message-State: AOUpUlH1WrypOTzzAIRm0aS2nxNzl0b41Pbkxwsl2FaGJPPhsXn/dl7d T/18Va7L03NTTKCF00fQuUh4sq6DhcQG+hWr8Fk= X-Google-Smtp-Source: AAOMgpda3b6HAfM0UxTNwnOVQXDMI07CJtxQFfeXSN12fIFFSlOHC9L1JtX4z5Bvg/YpnmQwcIwLqHcGCmn236ipAR4= X-Received: by 2002:a5e:9812:: with SMTP id s18-v6mr5440409ioj.117.1530806326945; Thu, 05 Jul 2018 08:58:46 -0700 (PDT) Original-Received: by 2002:a02:985d:0:0:0:0:0 with HTTP; Thu, 5 Jul 2018 08:58:26 -0700 (PDT) In-Reply-To: <20180705115259.4032dbea@jabberwock.cb.piermont.com> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4001:c06::236 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:226959 Archived-At: Ok I think I should let people know what my current plans are to avoid miscommunications: 1. Certificate pinning - HTTP Public Key Pinning is currently used by some browsers, but it's problematic. Chrome will remove it in Chrome 69[1] and go full-on Certificate Transparency (CT). 2. NSM has its own kind of certificate pinning, which is basically reinventing `$gnutls-cli --tofu`. It has a couple of problems, such as not being able to store multiple fingerprints (Google load balance between 2 certs signed by 2 different public keys), I have fixed them in my branch. I'll publish it soon. 3. There are a few security theatrics in NSM ATM, 'paranoid level is BS. If that level is justified, you can justify turning off your network card. I have removed it in my branch. 4. Certificate pinning is only a very very very small part of the entire suite of measures needed to securely deploy TLS on the client. There are a whole host of cipher suite and TLS extension checks missing in NSM currently. The current set of best practices RFC is RFC 7525. I have implemented most of the recommendations minus those not applicable to GnuTLS and some big ones like OCSP and CT. 5. The way `gnutls-min-prime-bits` was handled in whatever that bug number was was never appropriate. 256-bit default was never a good idea. I have defaulted it to `nil` in my branch, which tells GnuTLS to use an appropriate bit length according to the priority string (generally > 1024). If this breaks anyone's config, they have one of 2 options - 1) manually set `gnutls-min-prime-bits` back to whatever you were using and keep putting yourself at risk, and/or 2) complaint to your server's admin. 6. GnuTLS is behind in some features such as CT, and enables a shit ton of ciphers by default that OpenSSL has disabled. It's so seldomly used and looked at by researchers that I bet it's full of holes. Paradoxically, this is also its advantage. It's so seldomly used, mostly OpenSSL specific attacks don't apply to it. I'm not too concerned about GnuTLS at the moment. 7. Here's a preview of the latest set of checks in my fix-nsm-branch (defcustom nsm-tls-checks '((nsm-tls-check-verify-cert . low) (nsm-tls-check-same-cert . medium) (nsm-tls-check-version . medium) (nsm-tls-check-compression . medium) (nsm-tls-check-renegotiation-info-ext . medium) (nsm-tls-check-null-suite . medium) (nsm-tls-check-cbc-cipher . high) (nsm-tls-check-ecdsa-cbc-cipher . medium) (nsm-tls-check-3des-cipher . medium) (nsm-tls-check-rc4-cipher . medium) (nsm-tls-check-sha1-sig . medium) (nsm-tls-check-md5-sig . medium) (nsm-tls-check-rsa-kx . high) (nsm-tls-check-dhe-prime-kx . medium) (nsm-tls-check-dhe-kx . high) (nsm-tls-check-export-kx . medium) (nsm-tls-check-anon-kx . medium)) "This variable specifies what TLS connection checks to perform. It's an alist where the key is the name of the check, and the value is the minimum security level the check should begin. Each check function is called with the parameters HOST PORT STATUS SETTINGS. HOST is the host domain, PORT is a TCP port number, STATUS is the peer status returned by `gnutls-peer-status', and SETTINGS is the persistent and session settings for the host HOST. Please refer to the contents of `nsm-setting-file' for details. If a problem is found, the check function is required to return an error message, and nil otherwise. See also: `nsm-check-tls-connection', `nsm-save-host-names', `nsm-settings-file'" :version "27.1" :group 'nsm :type '(repeat (cons (function :tag "Check function") (choice :tag "Level" :value medium (const :tag "Low" low) (const :tag "Medium" medium) (const :tag "High" high))))) [1]: https://www.chromestatus.com/features/5903385005916160 [2]: https://tools.ietf.org/html/rfc7525 On Thu, Jul 5, 2018 at 4:52 PM, Perry E. Metzger wrote: > On Mon, 25 Jun 2018 19:33:49 +0200 Lars Ingebrigtsen > wrote: >> Jimmy Yuen Ho Wong writes: >> >> > It's all about collisions[1], it's mostly a precaution, as no one >> > has found an actual collistion for a cert yet, but Google has >> > found collision for PDF last year [2]. >> >> Ah, OK, then the SHA1 intermediate check isn't that vital. > > It is, actually. It's believed to be straightforward for national > actors to forge intermediate certificates at this point. > >> (I think the PDF collision was a cheat, anyway, since they just >> generated a lot of binary junk in a non-parsed section of the >> PDF. :-) ) > > One of the rules in this game is attacks get better with time. Not > that long after the first certificational attacks on MD5, it was > discovered that parties unknown, generally thought to be nation-state > actors, had been forging signatures on Microsoft software updates > using MD5 collisions to enable what they were doing. > > I would make sure that SHA-1 defenses are in place. > > Perry > -- > Perry E. Metzger perry@piermont.com