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: Deprecate TLS1.0 support in emacs Date: Wed, 12 Jul 2017 18:10:01 +0200 Organization: not if I can help it Message-ID: <8760ex63hi.fsf@gmail.com> References: <87o9sp7qok.fsf@gmail.com> <87zic9vk98.fsf@mouse> <87fue17mo5.fsf@gmail.com> <87tw2hvhob.fsf@mouse> Reply-To: emacs-devel@gnu.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1499875924 28623 195.159.176.226 (12 Jul 2017 16:12:04 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 12 Jul 2017 16:12:04 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 12 18:11:59 2017 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 1dVKEy-0006e5-CZ for ged-emacs-devel@m.gmane.org; Wed, 12 Jul 2017 18:11:52 +0200 Original-Received: from localhost ([::1]:54521 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dVKEz-00029g-IB for ged-emacs-devel@m.gmane.org; Wed, 12 Jul 2017 12:11:53 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36985) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dVKDd-00025c-I3 for emacs-devel@gnu.org; Wed, 12 Jul 2017 12:10:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dVKDZ-0003zs-PN for emacs-devel@gnu.org; Wed, 12 Jul 2017 12:10:29 -0400 Original-Received: from [195.159.176.226] (port=52277 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dVKDZ-0003yd-IY for emacs-devel@gnu.org; Wed, 12 Jul 2017 12:10:25 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1dVKDI-0001hu-4A for emacs-devel@gnu.org; Wed, 12 Jul 2017 18:10:08 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 59 Original-X-Complaints-To: usenet@blaine.gmane.org Mail-Copies-To: never Cancel-Lock: sha1:Rf8IagbQjC+UYosk6wFEsp64row= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 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:216545 Archived-At: Lars Ingebrigtsen writes: > Robert Pluim writes: > >> TLS1.0 is a seriously insecure protocol. I refrained from doing what I >> actually wanted to do, which is deprecate TLS1.1 as well. I think it's >> a disservice to allow TLS1.0 to continue to be used. > > It's no more "insecure" to read lists.gnu.org via HTTPS than it is via > HTTP, which is also an option. Denying the former while allowing the > latter is rather nonsensical. This is not about reading lists.gnu.org specifically, this is about all TLS protocol use from emacs. That should not use protocols that contain known serious security flaws if we can avoid it. When you choose to use https you have an expectation of security, unlike with http, so we should attempt to fulfill that expectation. > And if it had been available only via HTTPS, then refusing Emacs users > to access it would also have a security impact: Refusing access to > information is not "security", but the opposite. There is no refusal of access, just refusal of a specific protocol. If we implement your suggestion from below there won't even be refusal. >> That could be done with nsm, but only if you'll accept setting the >> default network-security-level to 'high, or adding a specific check >> for protocol version at 'medium. Option 1 looks something like this: > > No, `high' should be reserved for people that want higher than normal > network security. OK, then we should integrate a check like this into `medium'. TLS1.0 should be warned about in the default configuration. I'd argue that TLS1.1 should be as well, but we can always revisit that later. I'll see if I can come up with a patch tomorrow. > It might make sense to warn for TLS1.0 on `medium', though, but I'd have > to check what other web browsers do here. I think, for instance, that > Firefox still supports TLS1.0, and gives no warning, either. So unless > I've misunderstood the Firefox situation, I don't think we should do > anything here. Firefox still allows TLS1.0, unless you configure it in paranoid mode, like yours truly. > More long-term, I think it may make sense to just treat these "insecure" > protocols as if they were unencrypted, user interface wise, but that > would be up to each individual application (eww, package-list, etc) and > not further down in the network stack? Perhaps? No, we should just attempt to eradicate the use of TLS1.0 (and TLS1.1), not allow people to keep using them :-) I appreciate that's a strong opinion, but I definitely think we should strongly encourage people to move away from both of these protocols. Robert