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: Fri, 6 Jul 2018 07:42:22 +0100 Message-ID: References: <83o9g2uhju.fsf@gnu.org> <20180705115826.73c1d95e@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 1530859312 25449 195.159.176.226 (6 Jul 2018 06:41:52 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 6 Jul 2018 06:41:52 +0000 (UTC) Cc: Lars Ingebrigtsen , Paul Eggert , Emacs-Devel devel , "Perry E. Metzger" To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 06 08:41:47 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 1fbKR7-0006VJ-8q for ged-emacs-devel@m.gmane.org; Fri, 06 Jul 2018 08:41:45 +0200 Original-Received: from localhost ([::1]:56030 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fbKTE-0004qm-Eh for ged-emacs-devel@m.gmane.org; Fri, 06 Jul 2018 02:43:56 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41630) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fbKSB-0004ox-3S for emacs-devel@gnu.org; Fri, 06 Jul 2018 02:42:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fbKS8-0007SB-0f for emacs-devel@gnu.org; Fri, 06 Jul 2018 02:42:50 -0400 Original-Received: from mail-it0-x243.google.com ([2607:f8b0:4001:c0b::243]:39041) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fbKS4-0007Fy-Lc; Fri, 06 Jul 2018 02:42:44 -0400 Original-Received: by mail-it0-x243.google.com with SMTP id p185-v6so15702241itp.4; Thu, 05 Jul 2018 23:42:44 -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=Isuk1DrNlWH/EflbAoDRBQqu7gKxL4MDATpeAjeJxQc=; b=hur8PJa/GL9wa9grUOyngLzI3ylxC8mSmcDD0Yccg/A4TTKmxZe25g8Xz/qSOX4K30 aPYZpPlsw8TMPwwXjKv7VOlvlFzgJLNO7rKEoi+pad5AzZeQzkXiW+yj+AkOW0LgBc7M 7wia3QCSXbOn7iAHtfNMFgtzsK8iqXLoQdRIkpNdyQy4RcygoOFOrNr3XabBCvt+7erI Fa62CMnDWvkp7JsHS2tC9jDJ0dyEW7Q27kCPnxku+K2D3UDdQmVfdkXqmjGyUDjp67/z 7vCVmQNle7oB2hUKZFTU+hTpI9vWN1jhrN240vn9dSzjlxr5lFAf93zKgvVzIEci/Bmb Kyaw== 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=Isuk1DrNlWH/EflbAoDRBQqu7gKxL4MDATpeAjeJxQc=; b=sLhlB37rGHpKZdlIeLMVDOo2G9kXkyjDlJ8QGxTG8sFPdMdAhfbCNYfrUpTmhGE2MM 4PgFEL70I1MWYtdOy9D3ziLU6fo7AP8rAw0MH+JNOS5JFa65P1kCXMNcTdBxdc+NqRlT 4HLGe4JIYGew4w8UFOWEf9dJpCGw4zG9DGJUWUa4p1mnt3PfsdnEa2u6iBJEv/IPnLAN Gq0HQOzum55TJSid4gS2puWV3hD8Co+yenVADZLlOhsi6URAnfIlJPclai1K03scEXN0 5EIqKHis+NmKDMniCkBBhj123w+cyYwhrW9jR6BWhNN2iOqu+eD3udIRy63SRhxuR0PA EwFw== X-Gm-Message-State: APt69E1mZ0pxqfa0jqp7A6FpEh6mIHhibdD32oQFvMQ/s3Hid6X0TFQA cqS4XmqCAom929rCTtqO8uVIPi1CM/rlsnbdZyShwHDF X-Google-Smtp-Source: AAOMgpfBY8pnApbkVpKp50+cjJPX8fZYE/W/NC8wCG1ZRWmody2hT/w8RRiJVXrMOAcdTGG3ys2PzrY4p/t72Yz4kbk= X-Received: by 2002:a24:cf57:: with SMTP id y84-v6mr7299813itf.98.1530859363523; Thu, 05 Jul 2018 23:42:43 -0700 (PDT) Original-Received: by 2002:a02:985d:0:0:0:0:0 with HTTP; Thu, 5 Jul 2018 23:42:22 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4001:c0b::243 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:226986 Archived-At: Whoa that's a lot of emails in one day! I understand that some of you are concerned, I am too, that's why I raised this issue. Now, given the volume, I don't want to respond individually, so please allow me to summarize and address all of your concerns here. First of all, having read all of your comments, I don't think anybody is deliberately undermining Emacs' networks security. Emacs's network security is the way it is mostly because of a lack of knowledge and personnel. I don't think any of us is trying to hide that, and I think we all want it to be better. Therefore, instead of arguing the issue on moral ground, I propose we look at our common grounds and see what we've already agreed on. Before I dive deeper, here's a diff of my branch against master: https://github.com/emacs-mirror/emacs/compare/master...wyuenho:additional-nsm-checks I'll refer to this in the rest of this long email. You can have both freedom and security ----------------------------------------------------- A lot of us take Emacs' infinitely malleability as granted, so we don't even mention it, but that doesn't mean we don't care about freedom or are trying to be paternalistic. In my branch, I have kept the current NSM's structure - coarse grain security settings by setting `network-security-level`, and find grain security by setting `nsm-tls-checks`. This not only satisfies Eli's concern of providing reasonable settings while preserving the freedom of users to decide what's best for them, but also solves a more pertinent problem - the necessity to adjust individual network security checks quickly in case of a new kind of TLS attack outside of Emacs' release cycle. We can either change Emacs's release process or keep NSM malleable, the latter seems a quicker way out of this mess, and one which we can all agree on. Most of the checks are on `medium` level because of **secure by default** --------------------------------------------------------------------------------------------------- **Secure by default** is a mantra used by InfoSec professionals, in Emacs' lingo it means reasonable default settings. The reason 13 out of 17 checks in my branch are on `medium` level is *not* because I'm trying to mold NSM to such a way that its **security levels** are indistinguishable with **secury level**, but because most of those checks are RFC 7525's recommendation's for securely using TLS on the client. RFC 7525 is listed as BEST CURRENT PRACTICE by IETF in 2015. I have added a couple more checks to `medium` because things have evolved since 2015. The details for their inclusion are in the docstrings. As to `high`, those 3 checks ideally should be included in `medium` but can't for fear of being too naggy due to compatibility reasons. RSA key exchange is still widely deployed, so is DHE due to it being the only fallback for TLS 1.3. CBC mode is also widely a deployed fallback cipher. All of the above are known to be insecure a lot of times, but for me, **secure by default** means as secure *AND* practical as possible by default, so until RSA KX, DHE KX and CBC ciphers go away completely from the servers, I believe putting them on the `high` level is appropriate. More checks does not mean more inconvenience ----------------------------------------------------------------- NSM will only prompt you when a check fails *AND* these failed checks for a host have not been saved as exceptions. If you answer "session only" after the prompt, NSM will not prompt you again until you restart Emacs. If you answer "always", NSM will not prompt you again for those failed checks for that host as long as the exceptions are still saved on file. The ability of having a "chance to choose between the alternatives (convenience and safety) early enough that they won't beunsafe. The choice should come with an explanation of each option, first stating what situations it is recommended for, then what it does." is already implemented in master. Having said that, NSM currenly may prompt you many times if there is more than one security check failures, i.e. if your level is set to `high` and the server such as Google's is load balancing TLS connections with 2 or more certs with different fingerprints, and it's using SHA1 signatures, you will get 3 prompts. I have streamlined all of those in my branch so you only get prompted once for all the problems found. That's **more** convenience and "more" safety. You can have your cake and eat it too. Less knobs can also mean more convenience and security ------------------------------------------------------------------------------ The `paranoid` level is security theatre. All it does is ask if you'd like to connect to a server via TLS if you have never reached it before. Why is attempting to securely connect to a server by using a protocol that will authenticate it a cause for concern? Connecting to a server via TLS does not mean the user start transmitting confidential data immediately. That act comes when you sign up or log in. That's not TLS's job. For STARTTLS, if the server does not support TLS, you will have gotten a prompt for using a plain connection already, so why the extra prompt? Does it not give the user a false sense of more security? Will it mislead some innocent user to belive every host can be trusted under `high` level? If the answer to the last 2 questions were yes, I believe removing `paranoid` and its check is the right thing to do, even if only for the sake of giving the right expectation. Emacs is not (only) a browser, but that's a moot point ----------------------------------------------------------------------- Emacs' use base is diverse. People not only browse the Web with it, but read and reply to emails, browse newgroups, chat on IRC/Jabber/Slack, push code to Github etc., all of which require the network to be secured with TLS. While TLS is mostly used on the Web because of HTTPS, SSL/TLS has been mandatory for Gmail for many years now, Github also requires TLS for code push, and so do many chat servers. The way Emacs has deployed TLS either has a fault or it doesn't, it doesn't matter which protocol TLS is wrapping over. While I agree that blindly copying the security settings of the most widely deployed TLS clients that we call browsers may not necessarily be a good idea, it's also not a bad idea given Google and Mozilla's army of InfoSec people looking after them. In addition, I haven't copied them blindly. I have researched every single one of them by reading about a dozen RFCs and papers in the past few weeks, and only include them when applicable to Emacs' use of GnuTLS. See the docstrings for details. `gnutls-min-prime-bits` should be `nil` on Emacs 26.2 ----------------------------------------------------------------------- Setting `gnutls-min-prime-bits` to `nil` lets GnuTLS negotiate the highest possible bit length based on its priority string, which means at least 1008-bit since 3.3.0. If my and other's positions on this issue have not been clear, let me reiterate this - it was *never* appripriate to default `gnutls-min-prime-bits` to 256. The list of reasons are the following: 1. If a user's email server demands 256 bits, it's not a sufficient reason to sacriface the **secury by default** goal for the vast majority of users by defaulting it to 256 just so everyone is on the lowest common denominator possible. 2. US export regulation controls export of crypto components using DH > 512 bit prime length to rogue states[2], that means NSA can break DH with prime bits < 512, that also means possibly other state actors as well. 256-bit default means **enabling mass-surveillance** for our users world-wide. 3. If you are afraid of upping to > 1024 will interrupt many people's workflow, don't. SSLLabs's Key Exchange Strength scan[3] shows there's only 2.9% servers found using < 512 bit key exchange. 1024+2048+3076 bit servers cover ~ 95% of TLS server deployments out there. It makes no sense to sacriface 95% for 2.9%. See 1). 4. Even if it regressed for some poor guy's connection to an email server configured in the 80s, that's a **good** thing. If he ever comes back to complaint about it, we can direct him to complaint to the server admin instead, so we can all be safer. See 1) again. 5. Even if he turns out to have legitimate reasons to set prime bits to 256 bits, it's not Emacs' problem. He just has to M-x customize-set-value RET gnutls-min-prime-bits RET 256 RET. There is absolutely no reason whatsoever to default `gnutls-min-prime-bits` to 256, not even in the 90s. [1]: https://ee.stanford.edu/~hellman/publications/28.pdf [2]: https://www.bis.doc.gov/index.php/forms-documents/encryption/335-supplement-no-1-to-part-774-category-5-part-ii-information-security/file [3]: https://www.ssllabs.com/ssl-pulse/ OpenSSL is nice, but getting much improved network security out the door ASAP is nicer ---------------------------------------------------------------------------------------------------------------------- While OpenSSL certainly has its advantages, it is also a much bigger target. When dealing with security issues, one has to consider the economics. When economics are factored, an attacker will often ask if it make sense to spend a month working on an attack to target a small user base such as GnuTLS'. The answer to that is likely to be false. But if we are on OpenSSL, any new attack targeted towards it will make Emacs a target as well. In addition, these days I try to live by a motto - Don't let the perfect be the enemy of the good. Replacing GnuTLS with OpenSSL is significantly harder than writing a couple C functions to get the most out of GnuTLS. Replacing it without major regressions even harder. Besides, most of Emacs' network security problems do not come from it use of GnuTLS, but deficiencies in NSM. I believe Emacs' network security can get much better faster if we focus our efforts on the current design. Documenting security changes ----------------------------------------- Currently, Emacs' network security settings are poorly documented and widely misunderstood. There's only one page on the entire Emacs manual that briefly describes the checks NSM has, but it doesn't mention what its relation is with GnuTLS. There is also no mention of NSM or GnuTLS in the Emacs Lisp Reference whatsoever. I aim to improve it, but given the amount of work involved to bring Emacs' network security up to date, I'd rather submit another patch when the dust has settled. (*cough* feature creep *cough*) Jimmy On Thu, Jul 5, 2018 at 11:44 PM, Richard Stallman wrote: > [[[ To any NSA and FBI agents reading my email: please consider ]]] > [[[ whether defending the US Constitution against all enemies, ]]] > [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > I don't know what this issue concretely involves, so I don't have > an opinion about what concretely we should do. But I'd like to suggest > a possible avenue for choosing a good response. > > The idea is that we make sure users see a chance to choose between the > alternatives (convenience and safety) early enough that they won't be > unsafe. The choice should come with an explanation of each option, > first stating what situations it is recommended for, then what it does. > > > > -- > Dr Richard Stallman > President, Free Software Foundation (https://gnu.org, https://fsf.org) > Internet Hall-of-Famer (https://internethalloffame.org) > > On Thu, Jul 5, 2018 at 11:44 PM, Richard Stallman wrote: > [[[ To any NSA and FBI agents reading my email: please consider ]]] > [[[ whether defending the US Constitution against all enemies, ]]] > [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > > So far as I can tell and am aware, OpenSSL is fully free software. > > There are no unfree components. > > OpenSSL had, in the past, a license incompatible with the GNU GPL. > If its license is unchanged, using it with Emacs would require some > inconvenient work to install a license exception. > > That is assuming there is no non-FSF-copyrighted GPL-covered code > linked into Emacs. If there is some, that is not inconvenient but > impossible. > > > -- > Dr Richard Stallman > President, Free Software Foundation (https://gnu.org, https://fsf.org) > Internet Hall-of-Famer (https://internethalloffame.org) > >