From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Robert Pluim Newsgroups: gmane.emacs.devel Subject: Re: A couple of questions and concerns about Emacs network security Date: Fri, 06 Jul 2018 11:28:24 +0200 Message-ID: <87lgaoaf2f.fsf@gmail.com> 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 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1530869228 14877 195.159.176.226 (6 Jul 2018 09:27:08 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 6 Jul 2018 09:27:08 +0000 (UTC) Cc: eggert@cs.ucla.edu, Jimmy Yuen Ho Wong , emacs-devel@gnu.org, larsi@gnus.org, perry@piermont.com, rms@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 06 11:27:03 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 1fbN14-0003jr-Vw for ged-emacs-devel@m.gmane.org; Fri, 06 Jul 2018 11:27:03 +0200 Original-Received: from localhost ([::1]:56620 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fbN3C-0008Ej-9N for ged-emacs-devel@m.gmane.org; Fri, 06 Jul 2018 05:29:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40628) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fbN2W-0008EM-46 for emacs-devel@gnu.org; Fri, 06 Jul 2018 05:28:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fbN2S-000762-P4 for emacs-devel@gnu.org; Fri, 06 Jul 2018 05:28:32 -0400 Original-Received: from mail-wm0-x22d.google.com ([2a00:1450:400c:c09::22d]:34075) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fbN2S-00072O-FU; Fri, 06 Jul 2018 05:28:28 -0400 Original-Received: by mail-wm0-x22d.google.com with SMTP id s13-v6so3952820wmc.1; Fri, 06 Jul 2018 02:28:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:mail-followup-to:mail-copies-to :gmane-reply-to-list:date:in-reply-to:message-id:mime-version :content-transfer-encoding; bh=92RNTSMrMoKml+OLC8ql1kb3Rtq7yb0euN31IxNIBfo=; b=hhmFvfJ1VdL6+90nqkKUGobUaDMS6lY3RUfkHVqU0AzQNRj3lUp7mxuPg+E+sy15Dw cINyXDJuTofZxvU+PidDDKCkzQGhB5CUhFh/Kq8ZJ5Elffo1zntsLuVdvdyEBjX11dKb yNo775qipbk8jcYU6xNQ7P8RgHbYw3HAmXaHIe1NBRr7Ln9urDJSAi5c3h86L1DHg8zY EWOm+vEl37Nc1cmONXHdZNeF3qBQnFziMUPO6xCuBwqbZlxI+ARn4zIEHsYtQsJxPa7k XHTY+ux+jr/E0KAGPk96UmOpzR2XwOlEwtFPLUncmojJJ0VbVvO2ciW4cuJzK86EKrwh 6EOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:mail-followup-to :mail-copies-to:gmane-reply-to-list:date:in-reply-to:message-id :mime-version:content-transfer-encoding; bh=92RNTSMrMoKml+OLC8ql1kb3Rtq7yb0euN31IxNIBfo=; b=l5wYM6UocXn5pZCvQGqxuOS8J60ojpAB9iVlpnGdWhg+Ds651VLuX1U+IEcJV9KyPf iJUIwU++uHplhz65bmQwa15WgVizgF51zxvdaJaJXLxT5JeLMgQ5rEN8svqnBISdNt2N eF/NMr1Kc2+81RIYaS5F1mdcalxi+UTAUTUP87Z1Ret3bCJLO4Y4J5VW6Z9GnIeLmRTg RaWqgan5lXNcZTMDzPWfnVvlVf5cj5J8Y4dPAIzTLylAygQBJcFlWNW9e9y5WwXZQ2Bh QLIo+fSodafpqPXmPrgfR5EPr5j1YdwJ+MqYFFiR50LfgbVQlZIHyKl5aqVFAzQWyvyc RDuA== X-Gm-Message-State: APt69E3LqkWUp47vRVmMCiV9ysKINyyvz24fxgbdDqmr6ds9nbMuFbVY QUsjE6SlS0hfCHX3rY2Hxcnb8pmBqoY= X-Google-Smtp-Source: AAOMgpdt9W0r/GivtMhLZ85Wp6bJk/m7VPl76HR0nkTXgc96UDLKiN0dUQ7pR2yItP+2O/+EKhYgAQ== X-Received: by 2002:a1c:568a:: with SMTP id k132-v6mr5859027wmb.89.1530869306744; Fri, 06 Jul 2018 02:28:26 -0700 (PDT) Original-Received: from rpluim-ubuntu ([149.5.228.1]) by smtp.gmail.com with ESMTPSA id x6-v6sm10421859wrd.57.2018.07.06.02.28.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Jul 2018 02:28:25 -0700 (PDT) Mail-Followup-To: emacs-devel@gnu.org Mail-Copies-To: never Gmane-Reply-To-List: yes In-Reply-To: <83a7r4n5ht.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 06 Jul 2018 11:16:46 +0300") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:400c:c09::22d 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:226991 Archived-At: Eli Zaretskii writes: >> 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'.) > That=CA=BCs not quite my reading. Jimmy says: until RSA KX, DHE KX and CBC ciphers go away completely from the servers, I believe putting them on the `high` level is appropriate. so, it not a proposal to move them now. By the time that can be done, I suspect there will be other checks that can be added into 'high'. And most checks *should* be on 'medium', since many people will never change the defaults. > 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. Current security thinking no longer makes a distinction between 'internal' and 'external' networks, they're all assumed to be potentially dangerous, so 'low' would never be appropriate (except for honeypot type activities). > Same questions regarding a home network, separated from the outside > world by a firewall. I have such a network at home. I also have family members who are not necessarily as aware of security issues as I am, and who also possess network connections that are not secured by my firewall. > Why shouldn't Emacs cater to such use cases? > > 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? That I agree with, and that=CA=BCs why I use 'paranoid', limited as it currently is. > 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 don=CA=BCt think this is the right approach: the defaults should be as secure as we can make it whilst remaining reasonably convenient. I see no real use case for 4 separate classes that could meaningfully be used by a typical user (as distinct from 'low', 'paranoid', and the fine-grained settings, all intended for experts). >> 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. >>=20 >> 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). > Last, but not least, "emacs -Q" will not save any settings nor use > previously set ones. I=CA=BCm not sure what you=CA=BCre proposing here. These settings are per-= HOME, as all emacs settings are. Did you want some method for sharing the NSM settings? > That is why IMO we must make the default level strike a reasonable > balance between "more checks" and "convenience". It is IMO > unreasonable to base such a balance on the assumption that a dedicated > team of thugs with torture chambers are out there to get every one of > us. I think these cases are a minority, which should be catered to by > non-default security levels -- that's where 'high' and 'paranoid' > should come into the play. Even people not in physical danger deserve to have their communications protected from interception and snooping, as part of the basic human right to privacy and freedom from unjustified governmental tracking of their online behaviour. >> The `paranoid` level is security theatre. > > 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. > > I would very much like the security experts we have in our ranks help > us make these decisions by using their expertise to produce such an > analysis of the issues. Then this whole discussion would be much more > constructive, and I believe agreements could be reached much faster. > >> 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? > That=CA=BCs an excellent question to which I don=CA=BCt have an answer, alt= hough the 'open-network-stream' doc-string has: `starttls' -- Begin with an ordinary connection, and try upgrading via STARTTLS. If that fails for any reason, drop the connection; in that case the returned object is a killed process. and :use-starttls-if-possible is a boolean that says to do opportunistic STARTTLS upgrades even if Emacs doesn't have built-in TLS functionality. So perhaps we should ensure that all uses of it in emacs use that one or both of those where reasonable (the docstring for that function is long and complex, and all the possible interactions of various tls options are not obvious to me). As an aside, we should really try to steer people away from both cleartext *and* STARTTLS connections towards using direct TLS connections, but I=CA=BCm not sure what the right method is there. >> 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. Isn't it true that > some of the vulnerabilities are only or mainly specific to some > protocols or even some classes of servers? 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'. > > (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.) > >> `gnutls-min-prime-bits` should be `nil` on Emacs 26.2 That might be going a bit far, but I can certainly do that locally and see what happens. > 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. > 26.1 is out there. 26.2 has some fixes, but I see nothing that requires a quick 26.2 release (but my perspective is skewed by the fact that I build from git anyway). >> 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*) > > 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. > Documentation is good. I=CA=BCll see if I can find some time to work on that. > Thanks again for working on this. Likewise. Regards Robert