GNU bug report logs - #11267
24.0.95; gnutls.c: [0] (Emacs) fatal error: The Diffie-Hellman prime sent by the server is not acceptable (not long enough).

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 11267 in the body.
You can then email your comments to 11267 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Roland Winkler" <winkler <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.0.95;
	gnutls.c: [0] (Emacs) fatal error: The Diffie-Hellman prime sent by
	the server is not acceptable (not long enough).
Date: Tue, 17 Apr 2012 16:14:59 -0500

Today I switched for the first time to a new SMTP server I'll have
to use in the future.  It gives me the error messages

gnutls.c: [0] (Emacs) fatal error: The Diffie-Hellman prime sent by the server is not acceptable (not long enough).
gnutls.el: (err=[-63] The Diffie-Hellman prime sent by the server is not acceptable (not long enough).) boot: (:priority NORMAL :hostname foo.bar.com :loglevel 0 :min-prime-bits nil :trustfiles (/etc/ssl/certs/ca-certificates.crt) :crlfiles nil :keylist nil :verify-flags nil :verify-error nil :verify-hostname-error nil :callbacks nil)

Despite these error messages, Emacs is sending the mails I want to
send. In that sense, I cannot tell how relevant these error messages are.
For a nonexpert like myself, they are certainly irritating.


In GNU Emacs 24.0.95.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.20.1)
 of 2012-04-04 on regnitz
Windowing system distributor `The X.Org Foundation', version 11.0.10706000

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: C
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: en_GB.utf8
  value of $LANG: en_US.ISO-8859-15
  value of $XMODIFIERS: nil
  locale-coding-system: iso-latin-9-unix
  default enable-multibyte-characters: t

Message #8 received at 11267 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: "Roland Winkler" <winkler <at> gnu.org>
Cc: 11267 <at> debbugs.gnu.org
Subject: Re: 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: Wed, 18 Apr 2012 12:48:09 -0400

"Roland Winkler" wrote:

> gnutls.c: [0] (Emacs) fatal error: The Diffie-Hellman prime sent by the server is not acceptable (not long enough).
> gnutls.el: (err=[-63] The Diffie-Hellman prime sent by the server is not acceptable (not long enough).) boot: (:priority NORMAL :hostname foo.bar.com :loglevel 0 :min-prime-bits nil :trustfiles (/etc/ssl/certs/ca-certificates.crt) :crlfiles nil :keylist nil :verify-flags nil :verify-error nil :verify-hostname-error nil :callbacks nil)
>
> Despite these error messages, Emacs is sending the mails I want to
> send. In that sense, I cannot tell how relevant these error messages are.

Me neither. I think it means it is falling back to a non-encrypted
connection. You can try setting gnutls-min-prime-bits.

If that is so, the error message should probably say something along
those lines.

Message #11 received at 11267 <at> debbugs.gnu.org (full text, mbox):

From: "Roland Winkler" <winkler <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 11267 <at> debbugs.gnu.org
Subject: Re: 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: Thu, 19 Apr 2012 06:04:13 -0500

On Wed Apr 18 2012 Glenn Morris wrote:
> > Despite these error messages, Emacs is sending the mails I want to
> > send. In that sense, I cannot tell how relevant these error messages are.
> 
> Me neither. I think it means it is falling back to a non-encrypted
> connection. You can try setting gnutls-min-prime-bits.
> 
> If that is so, the error message should probably say something along
> those lines.

You are right. The "fatal error" disappears if I set
gnutls-min-prime-bits to 256. Yet this choice was just a guess based
on the custom declaration of this variable that suggests a value of
512.

I would appreciate if someone more knowledgable could review the
error messages that I have seen such that they become more helpful
for a nonexpert. Also it would be great if the docstring of
gnutls-min-prime-bits was more precise.

- What is the default value used for min-prime-bits if
  gnutls-min-prime-bits is nil?

- What are reasonable values for this variable such that a safe
  client-server handshake remains possible, if one needs to customize
  this variable? (Or the other way round: if a server wants to use a
  prime that is too small, it might really be the better solution to
  contact its sysadmin. Yet I couldn't tell when a prime falls below
  such a threshold.)

Thanks,

Roland

Message #14 received at 11267 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: "Roland Winkler" <winkler <at> gnu.org>
Cc: 11267 <at> debbugs.gnu.org
Subject: Re: 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: Thu, 19 Apr 2012 12:19:33 -0400

"Roland Winkler" wrote:

> - What are reasonable values for this variable such that a safe
>   client-server handshake remains possible, if one needs to customize
>   this variable? (Or the other way round: if a server wants to use a
>   prime that is too small, it might really be the better solution to
>   contact its sysadmin. Yet I couldn't tell when a prime falls below
>   such a threshold.)

I also wonder how it can be safer to fall back to no encryption at all,
rather than using weak encryption (if that is indeed what is happening).
Maybe it's to prevent a false sense of security, or something.

Message #17 received at 11267 <at> debbugs.gnu.org (full text, mbox):

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: Roland Winkler <winkler <at> gnu.org>, 11267 <at> debbugs.gnu.org
Subject: Re: 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: Thu, 19 Apr 2012 18:26:06 +0200

Glenn Morris <rgm <at> gnu.org> writes:

> I also wonder how it can be safer to fall back to no encryption at all,
> rather than using weak encryption (if that is indeed what is happening).
> Maybe it's to prevent a false sense of security, or something.

Are you sure that it's falling back to no encryption?  If it really does
that, then that's pretty crappy behaviour, in my opinion.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Message #20 received at 11267 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
Cc: Roland Winkler <winkler <at> gnu.org>, 11267 <at> debbugs.gnu.org
Subject: Re: 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: Thu, 19 Apr 2012 12:31:47 -0400

Lars Magne Ingebrigtsen wrote:

> Are you sure that it's falling back to no encryption? 

I'm not in the slightest bit sure! :)
A "fatal error" makes me think that's what happened.

Message #23 received at 11267 <at> debbugs.gnu.org (full text, mbox):

From: "Roland Winkler" <winkler <at> gnu.org>
To: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
Cc: Glenn Morris <rgm <at> gnu.org>, 11267 <at> debbugs.gnu.org
Subject: Re: 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: Thu, 19 Apr 2012 11:41:40 -0500

On Thu Apr 19 2012 Lars Magne Ingebrigtsen wrote:
> Glenn Morris <rgm <at> gnu.org> writes:
> > I also wonder how it can be safer to fall back to no encryption at all,
> > rather than using weak encryption (if that is indeed what is happening).
> > Maybe it's to prevent a false sense of security, or something.
> 
> Are you sure that it's falling back to no encryption?  If it really does
> that, then that's pretty crappy behaviour, in my opinion.

If the error message was more verbose, say by mentioning the
fallback the code uses, this could help nonexpert users like us to
understand the situation.

Message #28 received at 11267 <at> debbugs.gnu.org (full text, mbox):

From: Ted Zlatanov <tzz <at> lifelogs.com>
To: "Roland Winkler" <winkler <at> gnu.org>
Cc: Lars Magne Ingebrigtsen <larsi <at> gnus.org>, 11267 <at> debbugs.gnu.org
Subject: Re: 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: Tue, 24 Apr 2012 08:45:48 -0400

On Thu, 19 Apr 2012 11:41:40 -0500 "Roland Winkler" <winkler <at> gnu.org> wrote: 

RW> On Thu Apr 19 2012 Lars Magne Ingebrigtsen wrote:
>> Glenn Morris <rgm <at> gnu.org> writes:
>> > I also wonder how it can be safer to fall back to no encryption at all,
>> > rather than using weak encryption (if that is indeed what is happening).
>> > Maybe it's to prevent a false sense of security, or something.
>> 
>> Are you sure that it's falling back to no encryption?  If it really does
>> that, then that's pretty crappy behaviour, in my opinion.

RW> If the error message was more verbose, say by mentioning the
RW> fallback the code uses, this could help nonexpert users like us to
RW> understand the situation.

The error is coming straight from GnuTLS.  We can probably add a
Emacs-specific clarification to it, mentioning `gnutls-min-prime-bits'.
Would that be more helpful?  Or should I add a FAQ section to
emacs-gnutls.texi?

Usually this means the server should increase the size of the prime,
e.g. here are similar reports for msmtp and Sendmail:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=461802
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=440344

Dropping down to fewer bits in the DH prime is AFAIK not a serious
concern: you're not exposing your communications, only making the
exchange of the secret key slightly less secure.  So you're slightly
more vulnerable to a man-in-the-middle attack, but the connection itself
will be encrypted.  You can only turn off encryption by changing the
priority string.

ted

Message #31 received at 11267 <at> debbugs.gnu.org (full text, mbox):

From: "Roland Winkler" <winkler <at> gnu.org>
To: Ted Zlatanov <tzz <at> lifelogs.com>
Cc: Lars Magne Ingebrigtsen <larsi <at> gnus.org>, 11267 <at> debbugs.gnu.org
Subject: Re: 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: Tue, 24 Apr 2012 15:04:58 -0500

On Tue Apr 24 2012 Ted Zlatanov wrote:
> The error is coming straight from GnuTLS.  We can probably add a
> Emacs-specific clarification to it, mentioning `gnutls-min-prime-bits'.
> Would that be more helpful?  Or should I add a FAQ section to
> emacs-gnutls.texi?

In my opinion (a user who does not know much about the internals of
gnutls) mentioning `gnutls-min-prime-bits' by itself does not solve
the problem because I find that the doc string of this variable is
useful only for experts (see below).

Kind of related: "fatal error" sounds rather frightening, in
particular if one can only speculate how emacs worked around this
error. This could be clarified.

> Dropping down to fewer bits in the DH prime is AFAIK not a serious
> concern: you're not exposing your communications, only making the
> exchange of the secret key slightly less secure.  So you're slightly
> more vulnerable to a man-in-the-middle attack, but the connection itself
> will be encrypted.  You can only turn off encryption by changing the
> priority string.

If these details would be explained in the doc string of
`gnutls-min-prime-bits' and / or emacs-gnutls.texi would be helpful.

Also, it would be good (though I don't know whether a generic answer
is possible) to give some guidance on "reasonable" values for
`gnutls-min-prime-bits' as compared to cases where it would be
better to contact the sysadmin of the server requesting a change in
the setup of the server.

Roland

Message #34 received at 11267 <at> debbugs.gnu.org (full text, mbox):

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: "Roland Winkler" <winkler <at> gnu.org>
Cc: Ted Zlatanov <tzz <at> lifelogs.com>, 11267 <at> debbugs.gnu.org
Subject: Re: 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: Sun, 13 May 2012 21:04:24 +0200

"Roland Winkler" <winkler <at> gnu.org> writes:

> Also, it would be good (though I don't know whether a generic answer
> is possible) to give some guidance on "reasonable" values for
> `gnutls-min-prime-bits' as compared to cases where it would be
> better to contact the sysadmin of the server requesting a change in
> the setup of the server.

Yeah.  And I think `gnutls-min-prime-bits' should default to whatever
that "reasonable" is, because there's apparently quite a few servers out
there that has less bits than whatever the GnuTLS default is.  Which
isn't a very good user experience.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Message #37 received at 11267 <at> debbugs.gnu.org (full text, mbox):

From: Ted Zlatanov <tzz <at> lifelogs.com>
To: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
Cc: Roland Winkler <winkler <at> gnu.org>, 11267 <at> debbugs.gnu.org
Subject: Re: 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: Tue, 15 May 2012 04:24:56 -0400

On Sun, 13 May 2012 21:04:24 +0200 Lars Magne Ingebrigtsen <larsi <at> gnus.org> wrote: 

LMI> "Roland Winkler" <winkler <at> gnu.org> writes:
>> Also, it would be good (though I don't know whether a generic answer
>> is possible) to give some guidance on "reasonable" values for
>> `gnutls-min-prime-bits' as compared to cases where it would be
>> better to contact the sysadmin of the server requesting a change in
>> the setup of the server.

LMI> Yeah.  And I think `gnutls-min-prime-bits' should default to whatever
LMI> that "reasonable" is, because there's apparently quite a few servers out
LMI> there that has less bits than whatever the GnuTLS default is.  Which
LMI> isn't a very good user experience.

I'm OK with lowering it to 256.

Ted

Message #40 received at 11267 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> gnu.org>
To: Ted Zlatanov <tzz <at> lifelogs.com>
Cc: Lars Magne Ingebrigtsen <larsi <at> gnus.org>, Roland Winkler <winkler <at> gnu.org>,
	11267 <at> debbugs.gnu.org
Subject: Re: 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: Tue, 15 May 2012 23:16:20 +0800

Ted Zlatanov <tzz <at> lifelogs.com> writes:

> LMI> Yeah.  And I think `gnutls-min-prime-bits' should default to whatever
> LMI> that "reasonable" is, because there's apparently quite a few servers out
> LMI> there that has less bits than whatever the GnuTLS default is.  Which
> LMI> isn't a very good user experience.
>
> I'm OK with lowering it to 256.

Done.

Message #47 received at 11267 <at> debbugs.gnu.org (full text, mbox):

From: Ted Zlatanov <tzz <at> lifelogs.com>
To: n.mavrogiannopoulos <at> gmail.com, winkler <at> gnu.org
Cc: 15057 <at> debbugs.gnu.org, 16253 <at> debbugs.gnu.org, 11267 <at> debbugs.gnu.org
Subject: Re: 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: Sun, 09 Feb 2014 21:39:28 -0500

On Fri, 18 May 2012 04:38:01 -0700 (PDT) n.mavrogiannopoulos <at> gmail.com wrote: 

nm> On Tuesday, May 15, 2012 10:24:56 AM UTC+2, Ted Zlatanov wrote:
>> On Sun, 13 May 2012 21:04:24 +0200 Lars Magne Ingebrigtsen <larsi <at> gnus.org> wrote: 
>> 
LMI> "Roland Winkler" <winkler <at> gnu.org> writes:
>> >> Also, it would be good (though I don't know whether a generic answer
>> >> is possible) to give some guidance on "reasonable" values for
>> >> `gnutls-min-prime-bits' as compared to cases where it would be
>> >> better to contact the sysadmin of the server requesting a change in
>> >> the setup of the server.
>> 
LMI> Yeah.  And I think `gnutls-min-prime-bits' should default to whatever
LMI> that "reasonable" is, because there's apparently quite a few servers out
LMI> there that has less bits than whatever the GnuTLS default is.  Which
LMI> isn't a very good user experience.
>> 
>> I'm OK with lowering it to 256.

nm> Note that Diffie-Hellman group of 256-bits means that the communication can be
nm> decrypted by someone that stored the session. The default minimum
nm> accepted value in gnutls is already weak according to [0] (727 bits)
nm> but a good balance between security and compatibility. (other
nm> implementations like NSS have similar limits).

nm> If you need to support weaker servers you could warn your users of the consequences.

nm> [0]. http://www.keylength.com/en/3/

Hi Nikos,

We've continued the discussion in bug#15057 (about the min prime bits)
and bug#16253 (about the logging).  I've copied all three bug trackers
on this e-mail.  I hope that helps connect them for searches and when we
close them.

Roland, if you are satisfied with the direction taken in those bugs, we
can probably close this one.

Thanks
Ted

Message #50 received at 11267 <at> debbugs.gnu.org (full text, mbox):

From: "Roland Winkler" <winkler <at> gnu.org>
To: Ted Zlatanov <tzz <at> lifelogs.com>
Cc: 15057 <at> debbugs.gnu.org, 16253 <at> debbugs.gnu.org, n.mavrogiannopoulos <at> gmail.com,
 11267 <at> debbugs.gnu.org
Subject: Re: 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: Sun, 9 Feb 2014 21:06:37 -0600

On Sun Feb 9 2014 Ted Zlatanov wrote:
> Roland, if you are satisfied with the direction taken in those
> bugs, we can probably close this one.

I am still a bit confused concerning a "reasonable minimal value"
for gnutls-min-prime-bits.  Is 256 a value that I can feel
comfortable about?

Since this was made the default, I did not see again any error
messages.  But I cannot judge whether this means "all is OK".

Part of the problem is certainly that most users do not even know
that there is such a customizable user variable.  So one can only
hope that the default *is* reasonable.

Message #53 received at 11267 <at> debbugs.gnu.org (full text, mbox):

From: Nikos Mavrogiannopoulos <n.mavrogiannopoulos <at> gmail.com>
To: Roland Winkler <winkler <at> gnu.org>
Cc: 15057 <at> debbugs.gnu.org, Ted Zlatanov <tzz <at> lifelogs.com>,
 16253 <at> debbugs.gnu.org, 11267 <at> debbugs.gnu.org
Subject: Re: 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 09:28:09 +0100

On Mon, Feb 10, 2014 at 4:06 AM, Roland Winkler <winkler <at> gnu.org> wrote:
> On Sun Feb 9 2014 Ted Zlatanov wrote:
>> Roland, if you are satisfied with the direction taken in those
>> bugs, we can probably close this one.
> I am still a bit confused concerning a "reasonable minimal value"
> for gnutls-min-prime-bits.  Is 256 a value that I can feel
> comfortable about?

No. 256-bit DH is a bit harder than rot13 as encryption. I'd suggest
not to set the minimum acceptable size and let gnutls decide instead.
For broken servers that use very small sizes, you could disable the
DHE ciphersuites as described in the previous mails.

regards,
Nikos

Message #56 received at 11267 <at> debbugs.gnu.org (full text, mbox):

From: Ted Zlatanov <tzz <at> lifelogs.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Nikos Mavrogiannopoulos <n.mavrogiannopoulos <at> gmail.com>,
 Roland Winkler <winkler <at> gnu.org>, 15057 <at> debbugs.gnu.org, 16253 <at> debbugs.gnu.org,
 11267 <at> debbugs.gnu.org, Tassilo Horn <tsdh <at> gnu.org>
Subject: Re: 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 05:52:23 -0500

On Mon, 10 Feb 2014 09:28:09 +0100 Nikos Mavrogiannopoulos <n.mavrogiannopoulos <at> gmail.com> wrote: 

NM> On Mon, Feb 10, 2014 at 4:06 AM, Roland Winkler <winkler <at> gnu.org> wrote:

>> I am still a bit confused concerning a "reasonable minimal value"
>> for gnutls-min-prime-bits.  Is 256 a value that I can feel
>> comfortable about?

NM> No. 256-bit DH is a bit harder than rot13 as encryption. I'd suggest
NM> not to set the minimum acceptable size and let gnutls decide instead.
NM> For broken servers that use very small sizes, you could disable the
NM> DHE ciphersuites as described in the previous mails.

On Sun, 09 Feb 2014 18:58:34 -0800 Lars Ingebrigtsen <larsi <at> gnus.org> wrote: 

LI> Ted Zlatanov <tzz <at> lifelogs.com> writes:
>> See http://thread.gmane.org/gmane.network.gnutls.general/3181/focus=3299
>> 
>> Try, first of all, appending `!DHE-RSA:!DHE-DSS' to your GnuTLS priority
>> string to disable DHE.  ECDHE will not have the minimum bits message,
>> ever, IIUC.

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 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

* 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.

* 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.

Ted

Message #59 received at 11267 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Nikos Mavrogiannopoulos <n.mavrogiannopoulos <at> gmail.com>
Cc: 15057 <at> debbugs.gnu.org, 16253 <at> debbugs.gnu.org,
 Roland Winkler <winkler <at> gnu.org>, 11267 <at> debbugs.gnu.org,
 Tassilo Horn <tsdh <at> gnu.org>
Subject: Re: 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

Ted Zlatanov <tzz <at> lifelogs.com> 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/

Message #62 received at 11267 <at> debbugs.gnu.org (full text, mbox):

From: Nikos Mavrogiannopoulos <n.mavrogiannopoulos <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 15057 <at> debbugs.gnu.org, 16253 <at> debbugs.gnu.org,
 Roland Winkler <winkler <at> gnu.org>, 11267 <at> debbugs.gnu.org,
 Tassilo Horn <tsdh <at> gnu.org>
Subject: Re: 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: Tue, 11 Feb 2014 11:35:27 +0100

On Tue, Feb 11, 2014 at 6:09 AM, Lars Ingebrigtsen <larsi <at> gnus.org> wrote:
> Ted Zlatanov <tzz <at> lifelogs.com> 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.

(let's suppose that the chosen method is DHE)

4) The server presents its DHE parameters and you realize that they
are not acceptable.
5) Cannot do anything except abort the session, disable support for
DHE and go to (1).

>> 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.

Firefox in the past would happily connect to a server offering weak parameters.
This is changing now:
https://bugzilla.mozilla.org/show_bug.cgi?id=587234

So instead of emacs replicating what the insecure versions of firefox
did, it could provide security by default.

regards,
Nikos

Message #65 received at 11267 <at> debbugs.gnu.org (full text, mbox):

From: Ted Zlatanov <tzz <at> lifelogs.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Nikos Mavrogiannopoulos <n.mavrogiannopoulos <at> gmail.com>,
 Roland Winkler <winkler <at> gnu.org>, 15057 <at> debbugs.gnu.org, 16253 <at> debbugs.gnu.org,
 11267 <at> debbugs.gnu.org, Tassilo Horn <tsdh <at> gnu.org>
Subject: Re: 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: Tue, 11 Feb 2014 09:21:58 -0500

On Mon, 10 Feb 2014 21:09:25 -0800 Lars Ingebrigtsen <larsi <at> gnus.org> wrote: 

LI> (Emacs, being Emacs, might offer as an option a way to restrict all TLS
LI> connections to a smaller set of algorithms/levels, but that should not
LI> be the default.)

I think it should, as long as we make it easy to drop down the security,
as I described:

>> * 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.

LI> We would always try to get the most secure TLS connection possible, so I
LI> don't quite understand "reconnect"...

So my proposal is simply to provide two buttons "allow host X to connect
with lower DHE security [temporarily] [permanently]" and when the button
is clicked, customize `gnutls-algorithm-priority' to allow DHE to that
specific host.

`gnutls-negotiate' has to be changed slightly and the connection
rejection from insecure hosts will need to be handled in gnutls.c and
gnutls.el.

I think that's as seamless as we can make it, especially noting that
`gnutls-min-prime-bits' is deprecated since GnuTLS 3.1.7 (see
http://www.gnutls.org/manual/gnutls.html#index-gnutls_005fdh_005fset_005fprime_005fbits).

If we provide that simple UI, plus some help messaging, I think we can
disable DHE by default.  Based on Nikos' explanation, it seems to be the
best way forward.

Ted

Message #68 received at 11267 <at> debbugs.gnu.org (full text, mbox):

From: "Roland Winkler" <winkler <at> gnu.org>
To: Ted Zlatanov <tzz <at> lifelogs.com>
Cc: Nikos Mavrogiannopoulos <n.mavrogiannopoulos <at> gmail.com>,
 15057 <at> debbugs.gnu.org, 16253 <at> debbugs.gnu.org, 11267 <at> debbugs.gnu.org,
 Tassilo Horn <tsdh <at> gnu.org>, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: 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: Tue, 11 Feb 2014 16:49:06 -0600

On Tue Feb 11 2014 Ted Zlatanov wrote:
> So my proposal is simply to provide two buttons "allow host X to
> connect with lower DHE security [temporarily] [permanently]" and
> when the button is clicked, customize `gnutls-algorithm-priority'
> to allow DHE to that specific host.
> 
> `gnutls-negotiate' has to be changed slightly and the connection
> rejection from insecure hosts will need to be handled in gnutls.c
> and gnutls.el.
> 
> I think that's as seamless as we can make it, especially noting
> that `gnutls-min-prime-bits' is deprecated since GnuTLS 3.1.7 (see
> http://www.gnutls.org/manual/gnutls.html#index-gnutls_005fdh_005fset_005fprime_005fbits).
> 
> If we provide that simple UI, plus some help messaging, I think we
> can disable DHE by default.  Based on Nikos' explanation, it seems
> to be the best way forward.

Whatever customizability will be provided (permanently or
temporarily on the fly), I'd find it most important to have
documentation that allows the user to put the choices into
perspective. -- Is this feasible?  Certainly, we cannot expect that
the average user who is offered a pop-up menu with choices "allow
host X to connect with lower DHE security [temporarily]
[permanently]" that he can readily understand its implications and
put it into perspective. (DHE security lower than what?  Lower by
how much?  How insecure is that?)

(According to Murphy's law, this selection will probably pop up most
often, when the user is not in the mood to read long info pages...)

Roland

Message #71 received at 11267 <at> debbugs.gnu.org (full text, mbox):

From: Ted Zlatanov <tzz <at> lifelogs.com>
To: "Roland Winkler" <winkler <at> gnu.org>
Cc: Nikos Mavrogiannopoulos <n.mavrogiannopoulos <at> gmail.com>,
 15057 <at> debbugs.gnu.org, 16253 <at> debbugs.gnu.org, 11267 <at> debbugs.gnu.org,
 Tassilo Horn <tsdh <at> gnu.org>, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: 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: Tue, 11 Feb 2014 18:54:49 -0500

On Tue, 11 Feb 2014 16:49:06 -0600 "Roland Winkler" <winkler <at> gnu.org> wrote: 

RW> On Tue Feb 11 2014 Ted Zlatanov wrote:
>> So my proposal is simply to provide two buttons "allow host X to
>> connect with lower DHE security [temporarily] [permanently]" and
>> when the button is clicked, customize `gnutls-algorithm-priority'
>> to allow DHE to that specific host.
>> 
>> `gnutls-negotiate' has to be changed slightly and the connection
>> rejection from insecure hosts will need to be handled in gnutls.c
>> and gnutls.el.
>> 
>> I think that's as seamless as we can make it, especially noting
>> that `gnutls-min-prime-bits' is deprecated since GnuTLS 3.1.7 (see
>> http://www.gnutls.org/manual/gnutls.html#index-gnutls_005fdh_005fset_005fprime_005fbits).
>> 
>> If we provide that simple UI, plus some help messaging, I think we
>> can disable DHE by default.  Based on Nikos' explanation, it seems
>> to be the best way forward.

RW> Whatever customizability will be provided (permanently or
RW> temporarily on the fly), I'd find it most important to have
RW> documentation that allows the user to put the choices into
RW> perspective. -- Is this feasible?  Certainly, we cannot expect that
RW> the average user who is offered a pop-up menu with choices "allow
RW> host X to connect with lower DHE security [temporarily]
RW> [permanently]" that he can readily understand its implications and
RW> put it into perspective. (DHE security lower than what?  Lower by
RW> how much?  How insecure is that?)

I'm sure we can come up with more helpful messaging.  Does it have
to fit in 78 chars?  Can we use buttons?  If so, it could be like this,
going over 78 but not too much:

!! remote host X requires lower security [OK once] [OK always] [Cancel] [?]

With the ? taking the user to more details: a help message or even the
relevant section of gnutls.texi

If we can use a multi-line message it becomes easier, certainly.

The buttons could instead be a simple (y,Y,n,?) prompt.  But that could
be confusing to the inexperienced users we're trying to help.

I need some guidance :)  I don't know if this has been implemented in
another part of Emacs or other packages.

Thanks
Ted

Message #74 received at 11267 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Nikos Mavrogiannopoulos <n.mavrogiannopoulos <at> gmail.com>
Cc: 15057 <at> debbugs.gnu.org, 16253 <at> debbugs.gnu.org,
 Roland Winkler <winkler <at> gnu.org>, 11267 <at> debbugs.gnu.org,
 Tassilo Horn <tsdh <at> gnu.org>
Subject: Re: 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: Tue, 11 Feb 2014 20:29:09 -0800

Ted Zlatanov <tzz <at> lifelogs.com> writes:

> If we provide that simple UI, plus some help messaging, I think we can
> disable DHE by default.  Based on Nikos' explanation, it seems to be the
> best way forward.

But why would we disable DHE?  Prefer ECDHE over DHE, certainly, but I
don't understand disabling...

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Message #77 received at 11267 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: "Roland Winkler" <winkler <at> gnu.org>
Cc: 15057 <at> debbugs.gnu.org, 16253 <at> debbugs.gnu.org,
 Nikos Mavrogiannopoulos <n.mavrogiannopoulos <at> gmail.com>, 11267 <at> debbugs.gnu.org,
 Tassilo Horn <tsdh <at> gnu.org>
Subject: Re: 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: Tue, 11 Feb 2014 20:30:58 -0800

Ted Zlatanov <tzz <at> lifelogs.com> writes:

> I'm sure we can come up with more helpful messaging.  Does it have
> to fit in 78 chars?  Can we use buttons?  If so, it could be like this,
> going over 78 but not too much:
>
> !! remote host X requires lower security [OK once] [OK always] [Cancel] [?]

Yeah, that would be nice.  And, remember, somebody (ahem) also has to
write code to handle invalid certificates.  It could be done the same way.

And if the user types "OK always" for this (and for invalid
certificates), it should be stored using the customize functions.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Message #80 received at 11267 <at> debbugs.gnu.org (full text, mbox):

From: Ted Zlatanov <tzz <at> lifelogs.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Nikos Mavrogiannopoulos <n.mavrogiannopoulos <at> gmail.com>,
 Roland Winkler <winkler <at> gnu.org>, 15057 <at> debbugs.gnu.org, 16253 <at> debbugs.gnu.org,
 11267 <at> debbugs.gnu.org, Tassilo Horn <tsdh <at> gnu.org>
Subject: Re: 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: Wed, 12 Feb 2014 12:11:41 -0500

(I love how mangled the subject line became)

On Tue, 11 Feb 2014 20:30:58 -0800 Lars Ingebrigtsen <larsi <at> gnus.org> wrote: 

LI> Ted Zlatanov <tzz <at> lifelogs.com> writes:
>> I'm sure we can come up with more helpful messaging.  Does it have
>> to fit in 78 chars?  Can we use buttons?  If so, it could be like this,
>> going over 78 but not too much:
>> 
>> !! remote host X requires lower security [OK once] [OK always] [Cancel] [?]

LI> Yeah, that would be nice.  And, remember, somebody (ahem) also has to
LI> write code to handle invalid certificates.  It could be done the
LI> same way.

Yes, it's a similar UI.  After 24.4.  Is that available as a debbugs
tag, "target-version=24.5" or something?

LI> And if the user types "OK always" for this (and for invalid
LI> certificates), it should be stored using the customize functions.

Right.  I feel Customize is the right place to put certificate
exceptions.  The user can set their custom.el file to be
GnuPG-encrypted if they are concerned.

>> If we provide that simple UI, plus some help messaging, I think we can
>> disable DHE by default.  Based on Nikos' explanation, it seems to be the
>> best way forward.

LI> But why would we disable DHE?  Prefer ECDHE over DHE, certainly, but I
LI> don't understand disabling...

Nikos advocates (and I agree) that it's prudent to add
"!DHE-RSA:!DHE-DSS" to the default priority string.  We can make it easy
for the user to remove that exclusion or make a specific exception as
we've discussed.

Ted

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.