From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Perry E. Metzger" Newsgroups: gmane.emacs.devel Subject: Re: Bug#766395: emacs/gnus: Uses s_client to for SSL. Date: Sat, 25 Oct 2014 10:33:45 -0400 Message-ID: <20141025103345.56e8031e@jabberwock.cb.piermont.com> References: <20141022193441.GA11872@roeckx.be> <87zjcnj2k6.fsf@trouble.defaultvalue.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1414247651 7200 80.91.229.3 (25 Oct 2014 14:34:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 25 Oct 2014 14:34:11 +0000 (UTC) Cc: rms@gnu.org To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 25 16:34:05 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Xi2Pq-0008A3-Gy for ged-emacs-devel@m.gmane.org; Sat, 25 Oct 2014 16:34:02 +0200 Original-Received: from localhost ([::1]:53654 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xi2Pq-0004Ks-0Y for ged-emacs-devel@m.gmane.org; Sat, 25 Oct 2014 10:34:02 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48867) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xi2Pj-0004Ke-M5 for emacs-devel@gnu.org; Sat, 25 Oct 2014 10:34:00 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xi2Pb-0001B3-4E for emacs-devel@gnu.org; Sat, 25 Oct 2014 10:33:55 -0400 Original-Received: from hacklheber.piermont.com ([166.84.7.14]:50004) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xi2Pb-0001Ay-0V; Sat, 25 Oct 2014 10:33:47 -0400 Original-Received: from snark.cb.piermont.com (localhost [127.0.0.1]) by hacklheber.piermont.com (Postfix) with ESMTP id 8446C143B; Sat, 25 Oct 2014 10:33:45 -0400 (EDT) Original-Received: from jabberwock.cb.piermont.com (jabberwock.cb.piermont.com [10.160.2.107]) by snark.cb.piermont.com (Postfix) with ESMTP id 42AE92DFD25; Sat, 25 Oct 2014 10:33:45 -0400 (EDT) In-Reply-To: X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.25; x86_64-apple-darwin14.0.0) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 166.84.7.14 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:175830 Archived-At: On Sat, 25 Oct 2014 03:31:49 -0400 Richard Stallman wrote: > In an issue of security vulnerability, giving users the right > defaults is paramount. Allowing users to customize is no > substitute. Most users don't know about the issue. We need to DTRT > for them. YES. My proviso is that I generally think giving them an easy to use knob to let them do the wrong thing is also a mistake, because social engineering will often be used to convince them to turn off their security. If you can't avoid providing the knob, at the very least, you need to make the default correct and make the knob hard to turn by accident. On social engineering: I'm aware of people having been attacked by having their TLS encrypted connections disrupted by injected traffic while unencrypted ones were left unmolested. This convinced the users that there was some sort of problem with the encryption and that they should drop to the clear by unchecking the "use TLS" box in their GUI (the implications of which they didn't understand in the first place). Having done so, their (sensitive) connection and login credentials were then examined by the attackers. If unencrypted mode had not been permitted, the attack would not have succeeded. This was, in effect, a socially engineered downgrade attack. I recognize that some will again say "but most people face no such attacks and are doing nothing sensitive", but again, the problem is that the same software is used in sensitive and non-sensitive situations. Your software will not psychically intuit that you are a journalist doing a chat with an Iranian dissident while most people are just discussing video games with the same chat program. So, yes, at the very least, the default must be fully secure, but it is always best that there only be one mode, and it should be the secure mode. If you need to provide a knob, make sure the user has to do something inconvenient to get at it. Perry -- Perry E. Metzger perry@piermont.com