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 22:24:51 +0100 Message-ID: References: <83o9g2uhju.fsf@gnu.org> <20180705115826.73c1d95e@jabberwock.cb.piermont.com> <83a7r4n5ht.fsf@gnu.org> <83d0w0lapy.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 1530912236 4412 195.159.176.226 (6 Jul 2018 21:23:56 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 6 Jul 2018 21:23:56 +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 23:23:51 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 1fbYCk-00013Z-Ud for ged-emacs-devel@m.gmane.org; Fri, 06 Jul 2018 23:23:51 +0200 Original-Received: from localhost ([::1]:59692 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fbYEr-0007tK-Gt for ged-emacs-devel@m.gmane.org; Fri, 06 Jul 2018 17:26:01 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60469) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fbYEC-0007tD-Ud for emacs-devel@gnu.org; Fri, 06 Jul 2018 17:25:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fbYEB-0007ZZ-9a for emacs-devel@gnu.org; Fri, 06 Jul 2018 17:25:20 -0400 Original-Received: from mail-it0-x229.google.com ([2607:f8b0:4001:c0b::229]:50540) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fbYE5-0007P9-Q2; Fri, 06 Jul 2018 17:25:14 -0400 Original-Received: by mail-it0-x229.google.com with SMTP id u4-v6so18239424itg.0; Fri, 06 Jul 2018 14:25: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=thBCNJF4T9K4L8nfynVN7iZuYalImvhbxnPwKPodM1k=; b=rYwhVUfJwnZpZcSaqYVD5TEPQwmmZlaLBf8R58elEQsL+66rMmrPOOQOhfxilKZOtq jvXYHvOReH1Gg6PnfeMfjHyfB/30itxsZTl1aiY1PpqbEQSfysYwJbnqIHVE9xKH2V7u LF7/u06aheWWzvVe9J/xyppPk6B8df3+WthYi7KF5djiGVk0ryEwislqTkk04h8LrYX7 jEP1z6bWCXbF+wyXtrNAJHzkq6LD8DGmv5AdB6RfqntfsuKno4TEv9tEds+JZwklgX9i 7oTZ8NY8GDnX4ydr/t5nQlCRR2/nTTrPomvY/TCEIwpaJjc919LJcoWzKFto4wo6kwy+ 05aw== 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=thBCNJF4T9K4L8nfynVN7iZuYalImvhbxnPwKPodM1k=; b=DQWaav8zscDLW3JUixPG1qh9sNo14dJ9SgPWY7bRR+c1ITsVIwiYdAK71/KWZ6PjAl 6V0ybqpzO1Lk/N925xQx6VKw8nHs4QPpkARfFEVazC7DlQSmgRkimKrd4PEWn5UBno6E E9G1q9G7Rf8jvNVTszMwu6EQ1oQVmLV0AVuScTYbA+My2UqMGNIjJVSaW9+y0kW+jr16 EXtQxETdnbJUfhRzo1Tk7sAUC/X53LKA+UdQc0A//Zf5lS98CMoLwoyDM6t4zTlde8l3 jr22rRKINS5hRwlAutR7ApE6rwztsoIa8dQJrpjV5xq1IS1bJ6jkso5aBQKSJfN0Fq0D J8Qw== X-Gm-Message-State: APt69E2r1I/7XCzqYAx0gGoy/6tNSyXxxMznCeVNdHNrbwoCHjouKeTp IsauTZEJ7h2gfV8f1qz7PguiYvFJh6m2kHA+yA59jUgccik= X-Google-Smtp-Source: AAOMgpco4XUbntloYD+0hIJL+DHxjhdvBHqFndR4szwqUEctAUqjjTQwk+jW986gBXly1gkeO1kP2Rw7EUCGljZFbEE= X-Received: by 2002:a02:4187:: with SMTP id n7-v6mr9870683jad.86.1530912312564; Fri, 06 Jul 2018 14:25:12 -0700 (PDT) Original-Received: by 2002:a02:985d:0:0:0:0:0 with HTTP; Fri, 6 Jul 2018 14:24:51 -0700 (PDT) In-Reply-To: <83d0w0lapy.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4001:c0b::229 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:227024 Archived-At: > > Still, I'm asking whether it is appropriate to check only the > certificate. Aren't there any other checks that would fit 'low'? > Been waiting for you to say that :) In https://github.com/wyuenho/emacs/commit/35d720eceef5c9b1dc0553b7d2235bbb079b0036 , I've used Snowden as an epoch, and separated the checks known to be necessary before Snowden, the response post-Snowden, and preparations standard bodies and browser vendors do to prepare for TLS 1.3. The count is now 10 lows, 13 mediums (10 low + 3), and 17 highs (13 mediums + 4). >> > 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. > Alright... I cave. I see what you want now, you want an escape hatch for implicitly trusted network hosts. I'll make you a deal, if you can give me cross-platform C DEFUNs of getifaddr(3), getaddrinfo(3) and getnameinfo(3), I'll give you a `nsm-trust-local-network` boolean. If `nsm-trust-local-network` is non-nil, or a function that returns non-nil when `nsm-trust-local-network` is read, connecting to such hosts via TLS will be whitelisted automatically in memory. The docstring should say use this at your own risk. This should smooth out your home network situations, and like-wise for corporate intranets. >> 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? > You only land on the `network-stream-open-starttls` code path when you request :type 'starttls, I think this makes sense. This also is the approach recommended by RFC 2595, 3207 and 7425. The only protocols in Emacs that request STARTTLS, AFAIK, is IMAP, SMTP, POP3 and NNIP. I'm not sure if there are defcustoms in these packages that decides whether to terminate the connection if STARTTLS is not possible. Regardless, RFC 8314, fresh out of the oven in Jan this year demands Email related protocols to require TLS implicitly. STARTTLS will soon be obsolete anyway. > 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? > Most of the CAPITAL LETTER cute name vulns you can Google are targeted towards TLS, but demostrated with HTTP, but that doesn't mean their effects only are only limited to HTTPS. They are simply demostrated with HTTP so people can get a better sense of their severity as it's the most well-known protocol out there. The only instance of a cross protocol attack that only targets a specific application protocol that I'm aware of is an instance of CRIME called BREACH, of which there's no known effective countermeasure. There are however, plenty of implementation-specific vulns that do not apply to Emacs and GnuTLS. You may have heard of them. (*cough* Heartbleed *cough* gotofail *cough*) None of the checks I've thrown in are mitigations for OpenSSL implementation faults of targeted towards specific application protocols. They apply to ALL TLS connections. > >> 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. > I said you *might be*, and that's what the warning is about. Emacs can't decide for the user under such circumstances. No one ever said anything about assuming everyone is always under attack, we are saying user are exposed to these attacks, if you don't have these checks. These attacks may or may not be happening when you connect to a server, but you can certainly detect them or prevent them by using a combination of automated checks and human intervention. > > The NSM is not only about TLS, it's about any network connection Emacs > establishes. The security levels should not be only about TLS. > But it is only about TLS. Do you really want Emacs to prompt you when you are browsing http://www.some-random-guy.com/blog ? Browsers can do with a green padlock, the best Emacs can do is bleep out a message in the echo area or put a Unicode padlock in the mode line. But this is too application specific, it's best done in EWW or whatever. > > I'd be surprised if any of those packages used HTTPS to access Git > repositories. They'd have to reinvent Git. > They use Github's RESTful API to login, and clone the repo with `shell-command`. You can file issues and submit PRs on Github using Emacs too. > > 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. > Oh ye faithful disciple of the religion of Murphy's Law, may your hair show youthful color again by changing Emacs' release process to a Continuous Integration and Delivery process.