From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Florian Weimer Newsgroups: gmane.emacs.devel Subject: Re: Bug#766395: emacs/gnus: Uses s_client to for SSL. Date: Sun, 26 Oct 2014 13:45:01 +0100 Message-ID: <8761f7atki.fsf@mid.deneb.enyo.de> References: <20141022193441.GA11872@roeckx.be> <87zjcnj2k6.fsf@trouble.defaultvalue.org> <87mw8mzmxj.fsf@mid.deneb.enyo.de> <20141023143702.3897e618@jabberwock.cb.piermont.com> <8761fazkx7.fsf@mid.deneb.enyo.de> <20141023145721.12ed0820@jabberwock.cb.piermont.com> <87vbnay5lf.fsf@mid.deneb.enyo.de> <20141023154223.45f2c9eb@jabberwock.cb.piermont.com> <874muuihjh.fsf@uwakimon.sk.tsukuba.ac.jp> <20141023230048.13f8234a@jabberwock.cb.piermont.com> <87wq7pgpif.fsf@uwakimon.sk.tsukuba.ac.jp> <20141024171421.78720abe@jabberwock.cb.piermont.com> <87h9ys890o.fsf@lifelogs.com> <87egtvdz63.fsf@mid.deneb.enyo.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1414327534 31747 80.91.229.3 (26 Oct 2014 12:45:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 26 Oct 2014 12:45:34 +0000 (UTC) Cc: emacs-devel@gnu.org To: Lars Magne Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 26 13:45:27 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 1XiNCJ-0003PD-57 for ged-emacs-devel@m.gmane.org; Sun, 26 Oct 2014 13:45:27 +0100 Original-Received: from localhost ([::1]:56457 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XiNCI-00020b-Ob for ged-emacs-devel@m.gmane.org; Sun, 26 Oct 2014 08:45:26 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50983) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XiNC0-0001yN-MY for emacs-devel@gnu.org; Sun, 26 Oct 2014 08:45:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XiNBv-0004qE-P5 for emacs-devel@gnu.org; Sun, 26 Oct 2014 08:45:08 -0400 Original-Received: from albireo.enyo.de ([46.237.207.196]:42080) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XiNBv-0004nw-IZ for emacs-devel@gnu.org; Sun, 26 Oct 2014 08:45:03 -0400 Original-Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) id 1XiNBt-0001JR-IP; Sun, 26 Oct 2014 13:45:01 +0100 Original-Received: from fw by deneb.enyo.de with local (Exim 4.80) (envelope-from ) id 1XiNBt-0001sB-9y; Sun, 26 Oct 2014 13:45:01 +0100 In-Reply-To: (Lars Magne Ingebrigtsen's message of "Sun, 26 Oct 2014 12:42:50 +0100") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy] X-Received-From: 46.237.207.196 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:175856 Archived-At: * Lars Magne Ingebrigtsen: > Florian Weimer writes: > >> Uhm, if this happens, the server has been downgraded. The handshake >> will fail if a man-in-the-middle attempts to force the use of SSL 3.0, >> and both ends support something newer. (As far as I can tell, Emacs >> does not implement the vulnerable protocol downgrade code, unlike >> browsers.) > > Oh. Than what's all this fuss about, then? Just the normal churn of > "security professional" drama? It's unusual in the sense that the actual vulnerability in SSL 3.0 was fixed by subsequent protocol versions, beginning in 1999, and surprisingly few were eager to point this out. (It doesn't help that for non-technical reasons, what should have been SSL 3.1 is now called TLS 1.0.) I have no good explanation why browser vendors are so wedded to their broken fallback behavior. Even if you assume that they are balancing the their users' security needs and those of law enforcement agencies, some communications still do not make sense. Unfortunately, the early industry consensus (defined by those who were in the original pre-disclosure circle) appears to have been to claim that this fallback behavior is desirable, although it was never standardized by the IETF, and not implemented in most (any?) cryptographic libraries. But that secret circle failed to do their job properly, and their favorite remedy (TLS_FALLBACK_SCSV) is not available in most released TLS implementations and major TLS-using applications. As a result, a =E2=80=9Ccritical SSL vulnerability=E2=80=9D = hit the news, and security-conscientious operators had literally no option at hand to protect their user base, as it existed at that time (and not much has changed in the few weeks since then). Rather than admit to this failure and re-evaluate the browser fallback behavior (or the claimed impact of the well-known SSL 3.0 vulnerabilities), the message turned into =E2=80=9Cdisable SSL 3.0=E2=80=9D= , which is something that is doable today with some effort. (Some people even prefer cleartext over SSL 3.0 encryption, which is rather bizarre, but an understandable result of the situation.) But considering that the cryptographic libraries automatically upgrade away from SSL 3.0=E2=80=94if = you (as an application programmer) let them do their job, this step is rather pointless busywork. This effort only detracts from more important work, such as enabling encryption (with proper authentication, preferably) for additional services.