From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Lars Ingebrigtsen Newsgroups: gmane.emacs.devel Subject: Re: A couple of questions and concerns about Emacs network security Date: Sat, 23 Jun 2018 12:23:31 +0200 Message-ID: References: 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 1529749355 17738 195.159.176.226 (23 Jun 2018 10:22:35 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 23 Jun 2018 10:22:35 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: Paul Eggert , emacs-devel@gnu.org To: Jimmy Yuen Ho Wong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 23 12:22:31 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 1fWfgd-0004Ui-1n for ged-emacs-devel@m.gmane.org; Sat, 23 Jun 2018 12:22:31 +0200 Original-Received: from localhost ([::1]:37776 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fWfik-0004jH-78 for ged-emacs-devel@m.gmane.org; Sat, 23 Jun 2018 06:24:42 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39198) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fWfhn-0004hc-2h for emacs-devel@gnu.org; Sat, 23 Jun 2018 06:23:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fWfhi-0001ca-4Y for emacs-devel@gnu.org; Sat, 23 Jun 2018 06:23:43 -0400 Original-Received: from hermes.netfonds.no ([80.91.224.195]:39085) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fWfhh-0001bS-P7 for emacs-devel@gnu.org; Sat, 23 Jun 2018 06:23:38 -0400 Original-Received: from cm-84.212.221.165.getinternet.no ([84.212.221.165] helo=stories) by hermes.netfonds.no with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1fWfhb-0002qF-HW; Sat, 23 Jun 2018 12:23:33 +0200 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAALVBMVEXc3NsPDQ4FAwQDAQLw 8PAEAgOgn5/DwsFXVlf////+//77+/uxsK/+/v0FBAVGcKD1AAACPUlEQVQ4jdXSwWvTUBgA8G4M i9DDCmvdqdAnAU+5PHKvEpxjVegLn+xUKkjX0SAdlIaxHmaZmh4sFYr2s+1/UdQSCxVGixAGgiBF e7Cw4il/g99LW3dQD3oQTMhL8v3yJfm+9wL4660V+FPo/JfweeyPTt/py4vJZOxDKxfbvI/YeBiO hsP79HQ4vOHDwTmI+HtsKiLqeVcIYp4P7QjnADN8ICDK2NdtCesSVhTONZ4eRLhGoD5FnEPnkcGB Q/qdwXl0ythsCW0FxGbM2K1xAqaI+OECmiBmvXbk8VUJgp7aWMAHTVQR7x1wCUDbtzEBBvAGpC8j vq0YQGCAIrz9mCphVUlR3U0FdjlEBdjA1ucZqyzVQzwDOFaojulxhMXncEcRh1iPQSrIFKqjeuYx 5sMzJk7wDQPhUUum02pzCU0G14oV0Oh/hMxo1FTVh3oEmKoAGAAsytQqrnhTH7BCDeGGpnGNXkXw fAm3FINroKpMk92lYmveHBqyi3d1fUt+wyO4vgB8FQFBza6fLzLqi/lATNr2NmXa9hPbpqnFnH1C kAxlLNeyQkUaTkdWeVAolK2iBHMtVBgWh27BNI+G1sBMjNzQqYSR+dosWe6emzDLbnltWM5fSkq4 mTE/udagXBgFM6VMKRh0rXnGx77T0p0dx3G6O7R3Hb2rd29fLNGtxFFALyYOf1q7X3KDXHY4ylPM v/8BL0qD7DC7l1/e/261/xvo/MWrXuKyqPFFvBPQe/Lcoug83McJHdj5DjMJSLejSCPlAAAAAElF TkSuQmCC In-Reply-To: (Jimmy Yuen Ho Wong's message of "Sat, 23 Jun 2018 02:35:07 +0100") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 80.91.224.195 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:226611 Archived-At: Jimmy Yuen Ho Wong writes: > NSM is heavily dependent on GnuTLS, and it's not particularly good at > presenting NSM good peer status for NSM to do something about it. For > example, leaving all `nsm` and `gnutls` settings at default, this is a > list of URLs where NSM failed to ask me if I wanted to trust the cert. > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "https://rev= oked.badssl.com/"=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ;; fail, very > concerning Yes, Emacs should support the Online Certificate Status Protocol; patches welcome... > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "https://pin= ning-test.badssl.com/"=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 ;; fail, very > concerning For those who don't know what this is: Some browsers now ship with built-in lists of certificate hashes, so if you're visiting that site and presented with a different than expected certificate, you'll know that somebody else has issued a certificate for the site, and somebody has hijacked the connection. Or, perhaps, that they just lost the private key and had to generate a new certificate and now, oops, everybody that uses the browsers with the built-in list will be unable to visit the site. If Emacs is to do the HPKP (HTTP Public Key Pinning) thing, we can't really do that in the Emacs distribution itself, since Emacs is released so seldom. It makes sense for Chrome, which has a new release every three days (it sometimes seems like), but Emacs could do this via ELPA, I think. Whether it's worth doing is another issue; I think the jury is still out on that one... HPKP is also a "trust on first use" thing, where there's a HTTP header that instructs the user agent to pin the certificate. Since the NSM already has public key pinning implemented, if we want to support this, I think it might make sense to implement this on the url.el level -- make it call out to the NSM and ask it to pin a certificate if it detects the header. > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "https://sha= 1-intermediate.badssl.com/"=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ;; fa= il, very > concerning We discussed the sha1 authority thing last year and our conclusion was that we should move the sha1 check to `medium', and then I just forgot to do it. Sorry! I should have filed a bug report to remind myself... > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "https://3de= s.badssl.com/"=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ;; fail > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "https://moz= illa-old.badssl.com/"=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 ;; fail > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "https://dh-= small-subgroup.badssl.com/"=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ;; fa= il > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "https://dh-= composite.badssl.com/"=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 ;; fail These are all types of crypto that are now considered to probably be easy to hack by state actors (and others with a beefy laptop, probably). When we discussed these previously, we wondered whether we should do more layering of how we present these issues beyond warn/don't warn. For instance, Firefox happily accepts 3des.badssl.com and gives no warning, but it's kinda weak. Should the NSM propagate this information up to the calling application and then it could do... something? For instance, eww will display "secure" content with a green title bar. Should eww remove that stamp of approval from weak sites, even if we don't warn the user about it? I think so. > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "https://dh4= 80.badssl.com/"=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ;; fail > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "https://dh5= 12.badssl.com/"=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ;; fail These ones should be warned about on the `medium' level, I think, because they're really weak. > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "https://inv= alid-expected-sct.badssl.com/"=C2=A0=C2=A0=C2=A0=C2=A0 ;; fail, a bit > concerning Oh, geez, another TLA. This one is Signed Certificate Timestamps (SCTs), and is something I didn't know existed. :-) Neither does Firefox, so I think we're on the same level here. > If I set `network-security-level` to `'high`, only the dh480 and dh512 > tests passed. Oh, there's no test for dh480 and dh512 at all? That should, indeed, be fixed.=20 > I don't see how you are going to get around that without reinventing > CRL and HPKP in ELISP. HPKP is trivail to implement, I think? Especially in Lisp. The Certificate Revocation List and the pre-shipped HPKP thing is also easy to do; you just have to find a volunteer to update an ELPA package with the info... --=20 (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no