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: Thu, 13 Jul 2017 10:45:04 +0200 Organization: not if I can help it Message-ID: <871spkvi7j.fsf@gmail.com> References: <87o9sp7qok.fsf@gmail.com> <87zic9vk98.fsf@mouse> <87fue17mo5.fsf@gmail.com> <87tw2hvhob.fsf@mouse> <8760ex63hi.fsf@gmail.com> <87fue1v5lr.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 1499935545 11443 195.159.176.226 (13 Jul 2017 08:45:45 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 13 Jul 2017 08:45:45 +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 Thu Jul 13 10:45:31 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 1dVZkX-0002Fh-7J for ged-emacs-devel@m.gmane.org; Thu, 13 Jul 2017 10:45:29 +0200 Original-Received: from localhost ([::1]:58097 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dVZkc-0005OY-JX for ged-emacs-devel@m.gmane.org; Thu, 13 Jul 2017 04:45:34 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35242) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dVZkS-0005O7-Um for emacs-devel@gnu.org; Thu, 13 Jul 2017 04:45:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dVZkO-0002YT-F3 for emacs-devel@gnu.org; Thu, 13 Jul 2017 04:45:24 -0400 Original-Received: from [195.159.176.226] (port=51690 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dVZkO-0002Y1-8x for emacs-devel@gnu.org; Thu, 13 Jul 2017 04:45:20 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1dVZkB-0001Ef-Vx for emacs-devel@gnu.org; Thu, 13 Jul 2017 10:45:07 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 62 Original-X-Complaints-To: usenet@blaine.gmane.org Mail-Copies-To: never Cancel-Lock: sha1:uXwaox22jA7n8tKf/5//Looh0fM= 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:216571 Archived-At: Lars Ingebrigtsen writes: > Robert Pluim writes: > >> 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. > > It is a refusal to access a resource because somebody has determined > that a specific protocol (HTTP + TLS1.0) is something that our users > shouldn't be able to use. Allright. If we implement the checking in nsm, then that becomes "something our users get warned about but can be overriden, don't complain to us afterwards". > lists.gnu.org is, of course, just one example. > >> I appreciate that's a strong opinion, but I definitely think we should >> strongly encourage people to move away from both of these protocols. > > Encouragement is fine, but making our users switch to Firefox because of > this obsession with protocols isn't. We have no choice about it. People with bad intentions obsess over protocols far more than this. We should attempt to make their lives as hard as possible. > As more and more resources are being made available over encrypted > channels only, and as more and more of these (as a result of bad > maintenance and the like) get tagged as "invalid encryption", something > has to give. > > It seems like the current movement is to just to start ignoring whether > protocols are outdated, use invalid certificates and the like, and just > tell the user "you tried to access this via a secure channel. It's not, > but here's the content anyway". I happen to disagree with that movement, but if that's what you want emacs to do it's possible. > I may be misremembering, but I think the new Chrome beta is going in > this direction: No explicit refusals to access anything, but just a big > red X in the menu bar saying "UNSAFE". It is, you know, not less safe > than accessing via an unencrypted channel. It's less safe because some people won't notice the 'UNSAFE' indication, and will be unpleasantly surprised when things they thought were encrypted in transit aren't. Hence my preference for the prescriptive stance of banning TLS1.0 and TLS1.1 > I think this is probably the way Emacs should consider moving, too, for > eww and package-list. For other use, we may consider having the NSM > prompt the user for what to do with TLS1.0. But probably not just yet. OK. I'll just patch my emacs locally to disable TLS1.0 and TLS1.1 until then. At some point we should deprecate lisp/net/tls.el as well (or as a bare minimum remove its support for ssl), the builtin TLS support works very well. Robert