From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lars Ingebrigtsen Newsgroups: gmane.emacs.bugs Subject: bug#11267: bug#15057: 24.3.50; TLS error with reasonably high gnutls-min-prime-bits, bug#11267: 24.0.95; gnutls.c: [0] (Emacs) fatal error: The Diffie-Hellman prime sent by the server is not acceptable (not long enough). Date: Mon, 10 Feb 2014 21:09:25 -0800 Message-ID: <87ppmup75m.fsf@building.gnus.org> References: <87iozfl001.fsf@thinkpad.tsdh.org> <87li24zpg1.fsf@flea.lifelogs.com> <87lhxx6kr0.fsf@building.gnus.org> <871tzbaf1n.fsf@lifelogs.com> <874nsi12ng.fsf@niu.edu> <6mwr5d6l6e.fsf@fencepost.gnu.org> <20367.61741.640831.184941@gargle.gargle.HOWL> <20368.16452.379860.520133@gargle.gargle.HOWL> <87k4152t8j.fsf@lifelogs.com> <20375.1898.39520.582160@gargle.gargle.HOWL> <87ob2f8zdr.fsf@lifelogs.com> <21240.16957.410641.502622@gargle.gargle.HOWL> <87ppmvwu5h.fsf@building.gnus.org> <87d2iv8ck8.fsf@lifelogs.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1392095533 27371 80.91.229.3 (11 Feb 2014 05:12:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 11 Feb 2014 05:12:13 +0000 (UTC) Cc: 15057@debbugs.gnu.org, 16253@debbugs.gnu.org, Roland Winkler , 11267@debbugs.gnu.org, Tassilo Horn To: Nikos Mavrogiannopoulos Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Feb 11 06:12:19 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1WD5dq-0005X6-GH for geb-bug-gnu-emacs@m.gmane.org; Tue, 11 Feb 2014 06:12:18 +0100 Original-Received: from localhost ([::1]:59478 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WD5dp-000745-Mk for geb-bug-gnu-emacs@m.gmane.org; Tue, 11 Feb 2014 00:12:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59693) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WD5dg-00073l-7i for bug-gnu-emacs@gnu.org; Tue, 11 Feb 2014 00:12:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WD5da-0001DP-Tr for bug-gnu-emacs@gnu.org; Tue, 11 Feb 2014 00:12:08 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:34444) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WD5da-0001DL-Qd for bug-gnu-emacs@gnu.org; Tue, 11 Feb 2014 00:12:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WD5da-0004t4-Dx for bug-gnu-emacs@gnu.org; Tue, 11 Feb 2014 00:12:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 11 Feb 2014 05:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11267 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 11267-submit@debbugs.gnu.org id=B11267.139209546318701 (code B ref 11267); Tue, 11 Feb 2014 05:12:02 +0000 Original-Received: (at 11267) by debbugs.gnu.org; 11 Feb 2014 05:11:03 +0000 Original-Received: from localhost ([127.0.0.1]:42335 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WD5cd-0004rY-9N for submit@debbugs.gnu.org; Tue, 11 Feb 2014 00:11:03 -0500 Original-Received: from hermes.netfonds.no ([80.91.224.195]:33876) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WD5cX-0004qy-6i; Tue, 11 Feb 2014 00:11:01 -0500 Original-Received: from [204.14.154.233] (helo=building.gnus.org) by hermes.netfonds.no with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1WD5cH-0006E7-MJ; Tue, 11 Feb 2014 06:10:42 +0100 In-Reply-To: <87d2iv8ck8.fsf@lifelogs.com> (Ted Zlatanov's message of "Mon, 10 Feb 2014 05:52:23 -0500") User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.3.50 (gnu/linux) X-MailScanner-ID: 1WD5cH-0006E7-MJ MailScanner-NULL-Check: 1392700242.5987@nRN+9mreSxIwvY8/BRkaBw X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:85355 Archived-At: Ted Zlatanov writes: > LI> But aren't there lots of (or some) servers that only supports DHE and > LI> not ECDHE? > > There's no way to know until you connect, that's the heart of the > problem. So IIUC you'd have to either be potentially insecure all the > time (DHE enabled) or potentially fail connecting to some servers. I thought TLS worked like this: 1) You connect to a server. 2) A server says what encryption methods it supports 3) You choose one, and start talking in that method. So things like browsers have a pre-defined list of methods, in descending order of what they consider "more safe", so that ECDHE is used if available, etc. > I think the latter is the better option as a default, as long as we make > it clear (not in a *GnuTLS log* buffer but with `message' so it shows up > in the echo region and in STDERR in batch mode) that > > * the connection was rejected because the remote requires a lower level > of security I've basically never ever seen Firefox say "you can't talk to this server, because the TLS is too weak". Neither should Emacs. (Emacs, being Emacs, might offer as an option a way to restrict all TLS connections to a smaller set of algorithms/levels, but that should not be the default.) > * how to try allowing the less-secure connection (perhaps a simple > command to automate this, or even a clickable button, would be nicer > than asking the user to `customize-variable'). The original discussion > sort of settled on magically reopening the connection with less security > but I think that might be a disservice to the users. We would always try to get the most secure TLS connection possible, so I don't quite understand "reconnect"... > * why it's smarter to ask the server admin to upgrade their TLS > implementation > > Fitting all of that in a short readable message might be a challenge, > hence the button suggestion, but that's not ideal either. If the user has explicitly said "don't talk unless it has teh haxors leet mode", then that's not necessary, I would have thought. But I might be misunderstanding the problem completely. >"? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog http://lars.ingebrigtsen.no/