From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: A couple of questions and concerns about Emacs network security Date: Fri, 06 Jul 2018 17:06:49 +0300 Message-ID: <83d0w0lapy.fsf@gnu.org> References: <83o9g2uhju.fsf@gnu.org> <20180705115826.73c1d95e@jabberwock.cb.piermont.com> <83a7r4n5ht.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1530885958 1561 195.159.176.226 (6 Jul 2018 14:05:58 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 6 Jul 2018 14:05:58 +0000 (UTC) Cc: eggert@cs.ucla.edu, rms@gnu.org, rpluim@gmail.com, perry@piermont.com, larsi@gnus.org, emacs-devel@gnu.org To: Jimmy Yuen Ho Wong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 06 16:05: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 1fbRMp-0008W3-VA for ged-emacs-devel@m.gmane.org; Fri, 06 Jul 2018 16:05:48 +0200 Original-Received: from localhost ([::1]:58223 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fbROv-0007K7-FK for ged-emacs-devel@m.gmane.org; Fri, 06 Jul 2018 10:07:57 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42774) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fbROH-0007Jx-7e for emacs-devel@gnu.org; Fri, 06 Jul 2018 10:07:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fbROD-0005N6-Iu for emacs-devel@gnu.org; Fri, 06 Jul 2018 10:07:17 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:60183) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fbRNy-00057l-7E; Fri, 06 Jul 2018 10:06:58 -0400 Original-Received: from [176.228.60.248] (port=1664 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1fbRNr-0001VF-04; Fri, 06 Jul 2018 10:06:51 -0400 In-reply-to: (message from Jimmy Yuen Ho Wong on Fri, 6 Jul 2018 14:03:51 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:227006 Archived-At: > From: Jimmy Yuen Ho Wong > Date: Fri, 6 Jul 2018 14:03:51 +0100 > Cc: rms@gnu.org, Lars Ingebrigtsen , Paul Eggert , > Emacs-Devel devel , "Perry E. Metzger" , > Robert Pluim > > No, `low` verifies the certificate. Thanks. I was looking at nsm.el, so I guess I missed that. Still, I'm asking whether it is appropriate to check only the certificate. Aren't there any other checks that would fit 'low'? > > 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. I'm saying that it would be good to have a single setting in Emacs, ideally one of the security levels, that I could use in such environments, without being bothered about the details. > > 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. Sorry, I don't understand what that means in practice. Are you saying that on your branch Emacs doesn't by default distinguish between such home networks and public connections to Internet? If so, I don't think it's TRT. > > 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? There could be legitimate use cases for that. For example, testing nsm.el ;-) > I think it's good that you are trying to be thorough, but I think you > are over-complicating the situation here. I might agree with you, but not before we see the details of some of these "complications". > 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. Can you explain how a single site can be used to decide on what checks are appropriate? > 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. See, I'm getting these prompts from Firefox too frequently, and I'd hate Emacs to do the same. Even if these prompts are shown only once for every such site. > 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. We are talking about the defaults, so let's not start about fancy customizations. Selecting a non-default security level should be the only customization pertinent to this discussion. > > 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. Hmm... I would consider this a bug, as it means "emacs -Q" behaves differently on different systems and with different users. > 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. Robert just did, see his post. > >> 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. So we prompt for a plain connection when TLS is available, but unconditionally fail it when TLS isn't available? Does that make sense? > > 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. TLS is protocol agnostic, but vulnerabilities aren't, right? I mean, some of the vulnerabilities are more likely (or even only) met when using TLS with some protocols and not with others, right? > > 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. That might be "good enough", but I'm still not convinced that we cannot do better by default. > In such circumstances, you might be under an active MITM attack, > hence the warning prompt again. Yes, I might, but is it reasonable to have the defaults assume _everyone_ is _always_ under such an attack? I don't think so. > > 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. The NSM is not only about TLS, it's about any network connection Emacs establishes. The security levels should not be only about TLS. > > (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. I'd be surprised if any of those packages used HTTPS to access Git repositories. They'd have to reinvent Git. > > 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`. I didn't say the change is complex. What bothers me is entirely different effects this change could have. > I guarantee you this will cause no problem whatsoever. Sorry, I cannot accept such guarantees. I have too much gray hair. > Users will applaud you if you do this for Emacs 26.2. Been there, done that, can show the scars. > > 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 in advance.