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 14:03:51 +0100 Message-ID: References: <83o9g2uhju.fsf@gnu.org> <20180705115826.73c1d95e@jabberwock.cb.piermont.com> <83a7r4n5ht.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1530882237 32185 195.159.176.226 (6 Jul 2018 13:03:57 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 6 Jul 2018 13:03:57 +0000 (UTC) Cc: Paul Eggert , rms@gnu.org, Robert Pluim , "Perry E. Metzger" , Lars Ingebrigtsen , Emacs-Devel devel To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 06 15:03:53 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 1fbQOu-0008Ha-QS for ged-emacs-devel@m.gmane.org; Fri, 06 Jul 2018 15:03:53 +0200 Original-Received: from localhost ([::1]:57950 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fbQR2-0004Kv-2b for ged-emacs-devel@m.gmane.org; Fri, 06 Jul 2018 09:06:04 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55939) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fbQPS-0003nx-Cs for emacs-devel@gnu.org; Fri, 06 Jul 2018 09:04:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fbQPQ-0002WK-1l for emacs-devel@gnu.org; Fri, 06 Jul 2018 09:04:26 -0400 Original-Received: from mail-it0-x22f.google.com ([2607:f8b0:4001:c0b::22f]:38245) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fbQPF-0002Pk-TW; Fri, 06 Jul 2018 09:04:14 -0400 Original-Received: by mail-it0-x22f.google.com with SMTP id v71-v6so6459174itb.3; Fri, 06 Jul 2018 06:04:13 -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=uZxmY7ITOA4fUoRDBVQM9hnJKdxqq0WbQysqqBndjTw=; b=dWFQBkozJQd6i50qur6w24myG6BfdKUdj2Wcbni/WUY3pxPgHjaNoQGzSTklU3PTzG JWemboyNwK8eMbfjJOvOVJKf9e08rVSbozjW8MnmM5pwutKVUADOJubfi51kbm22LZjF /B+OPi1s85RfeQnV/q/m1jyfthcmJDZdU/9OCAm29s43Ghb09bf6TQO1Z2DU1U1YFwV0 qUUEdfF7Sauq+iCazkmhc4oMiIVaQI66IdnOegrrLyOPflSkSAsFWZwU2kViE87USrT5 J3rhk7Mis6EjWKaJ7c4HSdzLxPcDIcDYfqNBZRUkYo/UWGjrPUUpII23IlkRmNjKw/Xo 54Gg== 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=uZxmY7ITOA4fUoRDBVQM9hnJKdxqq0WbQysqqBndjTw=; b=MtwPbyWQ8UsiTJ9RvGQTq8HqzVqFh3bnnsi3Yn4MJvhgaLnjUBH6RD5Ce1mUmPn3Qn tGK22PZQxkKPVsldLRSEEgxHqVFTLq7doNYxLYNCM6Fq/j9jeCfyEqmeuun4EFwc83hi LiVap7G7JI/ZfACWMaVQ/gL5i8VbZLq8YxMQYizYCPe3cXhk4ENpRDFVlJEhuksH8z2k /WjOzJIK6uj+CwgANCg15eIpKuQiFka6ZPe3r2u+TCZKrm0w+lxfgUZCkuQM7b0yU+JY Qgi8N6LPMoiFcmDRTlFKDz7xsGQE82nC7gIbVJdRSNW83Iqs1NRU4nF4Ys/6ixxgxI4T bUjQ== X-Gm-Message-State: APt69E3d5BdqClOEyFJT7Tacw7xgk543YrpVyZiri5Z8a07MCUDzgV02 BfQYWxp4pX+klgb5YzluTa4lC+nxrScNQnTxTmjN4BS76Kw= X-Google-Smtp-Source: AAOMgpdxtkelbqYjmkcrUV+7qlhxFpBfhFsW6sdI/4DfKp81GIwUCjNUd/oSSA+3tZyeWuUrqAC6cn2/am7GpntZbyc= X-Received: by 2002:a24:5442:: with SMTP id t63-v6mr8746267ita.31.1530882251948; Fri, 06 Jul 2018 06:04:11 -0700 (PDT) Original-Received: by 2002:a02:985d:0:0:0:0:0 with HTTP; Fri, 6 Jul 2018 06:03:51 -0700 (PDT) In-Reply-To: <83a7r4n5ht.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4001:c0b::22f 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:227002 Archived-At: > >> 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` > > I'm still questioning how can this be TRT. Please remember that > 'medium' in Emacs really means 'minimum', because 'low' has no > security checks at all. How can it make sense to have _all_ the > checks on the _minimum_ level? (I say "all" because you clearly think > 'high' and 'paranoid' should be removed, and their checks, those which > make sense, moved into 'medium'.) > No, `low` verifies the certificate. That's always been the case, its just on master, they are separate from the protocol checks. In my branch, I have broken up the giant and separate `nsm-check-certificate` function and reimplemented it as 2 check functions in `nsm-tls-checks`. There's no distinction between certificate checks and protocol checks anymore, whatever that means originally. A check for a TLS connection is just that, a TLS check. As such, `medium` is not minimum, `medium` means default, i.e. verifies the cert + checking for unsafe TLS extensions and cipher suites. `high` is `low` + `medium` + checking for more unsafe cipher suites that are still widely deployed but warning you under most circumstances may produce excessive nagging (It's getting very rare these days tho, due to Google and Mozilla flexing their muscles, so to speak). > Suppose I work in Emacs on an internal secure network that is > physically disconnected from the Internet (many enterprises, including > my daytime job, have such stand-alone networks as a matter of > routine). Why would I need all the checks you propose on such a > network? OTOH, I don't want to go to 'low' (i.e. 'none') on such > networks, because who knows what viri and other calamities can be once > in a blue moon present on some of the machines on that network. > The answer to this question very much depends on how this intranet is setup to mirror the most current best practices for the wider internet. If they are close, as they should be, all you have to do is give your org's CA PEM file to `gnutls-trustfiles` and you are all set. If your org only relies on a physical separation, and does not deploy TLS internally, your connections either go through `nsm-check-plain-connection` in the case of SMTP/POP/IMAP, which does nothing unless a previous connection to your internal email server was done in a TLS connection, or not go through NSM at all. For anything between these 2 extremes, you can easily adjust the checks in the new defcustom that is `nsm-tls-checks`, which allows you to insert and delete individual cons' in the alist in Customize. Expanding the network security section in the manual to cover what these checks are and how to adjust them should help users in these orgs figure out what to do. > Same questions regarding a home network, separated from the outside > world by a firewall. > > Why shouldn't Emacs cater to such use cases? > Do you run your own CA and TLS servers at home? Do you use Google at home? If you answer no and yes, then the list of checks in my branch is designed specifically for you. > On the other end, there are legitimate use cases where users might > need to access sites and servers known in advance to be dangerous. > Why shouldn't Emacs provide a 'paranoid' set of settings for such use > cases? > If they know a site might be dangerous a priori and still decide to visit it, may be The Emacs Way is to treat them like adults? > The RFCs you cite and the vulnerabilities they describe should IMO be > carefully analyzed, in the context of typical Emacs jobs that require > network connections, and then we should grade them by their > importance, divide them into 3 or 4 meaningful classes (a.k.a. > "levels"), and let users change their settings in meaningful ways by > changing the level. Fine-grained settings should IMO also be > provided, but they cannot be the only solution that we offer our > users, precisely because not everyone has time to study each > individual feature, but they normally will have time to read a > description of 3 to 4 levels and decide which one is for them, > especially if we describe them in terms that are related to the > general environment rather than to specific vulnerabilities, similar > to how many laptops ask you to select whether the new connection is > for "home network", "enterprise", or "public network" -- that's > something that every user can normally answer. > I think it's good that you are trying to be thorough, but I think you are over-complicating the situation here. The answer to these situations can be found by doing what I call "The Google Test" - Do you use Google on this network? If yes, you need the checks in my branch. If no, adjust the checks in `nsm-tls-check` as you see fit. Read the manual to find out how. For weird enterprise networks, if you get a prompt, you can whitelist the intranet site by typing a for always, and you don't get a prompt the next time. I think this is a good balance between convenience and safety. Lars' good ideas hold up very well here. If a user wants more convenience, he can write a check function that distinguishes these network types you speak of. Let the thousand flowers bloom in the package ecosystem for these things. Emacs only needs to provide some hooks and a nice interface for them, which is NSM. >> 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. > > These improvements are good (provided that they indeed work in > practice -- I will have to try them), but IMO they are not enough. > You assume each one of us has only one Emacs installation, with only > one HOME directory where settings are saved. But that is profoundly > not true: people have Emacs installed on several machines, with HOME > directories not necessarily shared. Emacs developers might very well > have several HOME directories on the same machine, for testing > purposes (I certainly have such setups and use them all the time). Tons of people already put their init files or the entire `user-directory` in a git repo and share them across installations. `nsm-settings-file` by default goes into your `user-directory`, they can very well put it into a git repo. > Last, but not least, "emacs -Q" will not save any settings nor use > previously set ones. > Not true. The settings NSM saves do not go into your init file or custom-file. They are by default saved in user-directory/network-settings.data, and NSM will use the settings saved there even during emacs -Q. > > If the 'paranoid' level doesn't do a useful job, it should be modified > to do a useful job. The decision whether we even need such a level > should IMO be one we take _after_ classifying the vulnerabilities and > their prevention measures, not before. It is quite possible we will > decide that we don't need such a level, but the fact it is not useful > today doesn't mean it cannot be useful. > TBH, while `low` may be useful once in a blue moon for testing purposes, I can't think of anything that can justify a `paranoid` level that is not better served by unplugging your network card. But do let me know if you can think of some. >> 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 what you say cover Emacs built without TLS support, for example? > If I understand the code in `network-stream-open-starttls` correctly, you won't even be able to establish a connection if neither GnuTLS is linked into Emacs nor a `starttls-command` is available. >> 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. > > I don't see how your conclusion necessarily follows from the fact that > most or all protocols we use are secured with TLS. TLS is protocol agnostic protocol. If the way Emacs implements TLS has a vuln, the vuln will show up for all connections for all protocols when a user opens a network stream that requires TLS or STARTTLS. > Isn't it true that > some of the vulnerabilities are only or mainly specific to some > protocols or even some classes of servers? For the protocols TLS is wrapping, no. For servers, maybe. I'm quite certain that a lot of schools have woefully outdated TLS settings for SMTP/POP3/IMAP. For those types of servers, you may get a prompt from NSM per the default settings. But then again, you can easily whitelist the cert after visually verifying it. It's fire-and-forget, done once over the lifetime of the network-settings.data file type of deal. After that, NSM will protect you if you are served a different cert identified by its public key ID when connecting to a host previously visited. In such circumstances, you might be under an active MITM attack, hence the warning prompt again. All of the checks in `nsm-tls-checks` is there to prevent MITM, so if you are connecting to a server that NSM considers unsafe due to outdated TLS settings, giving you a warning is exactly the right thing to do as opposed to silently ignoring the problem by relaxing the constraints. > Is it really true that, > say, fetching and sending email on the one side, browsing s Web page > on the other, and chatting on the third, all bump into the same set of > risks? This is the kind of analysis I'd like to see before we make up > our minds what should be in 'medium'. Different application protocols contain different kinds of attack vectors, that's true. But those application-specific security measures are not the job of TLS. TLS stands for Transport Layer Security, it's primary jobs are verifying the identity of the server you are connecting to, ensuring the traffic to that server has not been tempered and keeping the traffic confidential, that is to say, only the client and the server can read the messages. TLS' primary function is to prevent MITM attacks, which contains passive attacks such as eave-dropping, or active attacks such as phising. Deploying TLS it's only one of the many security measures for an application. In addition to TLS, browser have Single-Origin-Policy, Content-Security-Policy, HTTP-Strict-Transport-Security and a whole host of other techniques to achieve defence-in-depth. Email clients typically employ spam-filters, heuristics to detect phising emails, blocking Javascripts and loading of tracking images. With that said, if we cannot secure the communication channel, all hopes are lost as a lot of things the attackers want by launching these application specific attacks are easily obtainable by intercepting your connection. > > (Btw, is Github relevant to the issue at hand? We access Git > repositories by invoking Git, we don't access them from Emacs > directly, AFAIK.) There are all kinds of github integration packages on Melpa. I think they tend to clone repos using HTTPS because it's permeable to firewalls. > >> `gnutls-min-prime-bits` should be `nil` on Emacs 26.2 > > As I already said, this will delay the release of Emacs 26.2 by many > moons. From my POV, doing so is not a good idea, as we already have > quite a few non-trivial bugfixes on the emacs-26 branch, but if no one > else is bothered, I'm fine with doing that. > > IOW, this is a project-management decision, not a security-related > decision. > This only requires deleting 2 lines of comments and s/256/nil, and perhaps say a few words in the docstring to let users know under what circumstances should they be adjusting `gnutls-min-prime-bits`. All of which takes 5 mins maximum. I guarantee you this will cause no problem whatsoever. If a user has customized `gnutls-min-prime-bits`, changing the default will have no visible effect to them. For those who haven't, it's a small step towards having Emacs's network security catching up to 2015. This is a super-low-hanging fruit. Users will applaud you if you do this for Emacs 26.2. > > IMO this is a mistake, and I urge you to reconsider. While there's no > need to follow up each code change on a scratch branch with a suitable > documentation change, I think we already have a lot of added turf to > document, and having at least that well documented will go a long way > towards the goal. It could even make this discussion more efficient > and more rational, since we would all be on the same page wrt the > issues being discussed, even though not all of us are experts on these > matters. > I'm beginning to think this is probably a good idea. > Thanks again for working on this. Thank you for your thoughtful responses!