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

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

[Roland Winkler]

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

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

[Glenn Morris]

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

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

[Roland Winkler]

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

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

[Glenn Morris]

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

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

[Lars Magne Ingebrigtsen]

Glenn Morris <rgm@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/

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

[Glenn Morris]

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.

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

[Roland Winkler]

On Thu Apr 19 2012 Lars Magne Ingebrigtsen wrote:
> Glenn Morris <rgm@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.

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

[Ted Zlatanov]

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

RW> On Thu Apr 19 2012 Lars Magne Ingebrigtsen wrote:
>> Glenn Morris <rgm@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

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

[Roland Winkler]

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

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

[Lars Magne Ingebrigtsen]

"Roland Winkler" <winkler@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/

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

[Ted Zlatanov]

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

LMI> "Roland Winkler" <winkler@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

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

[Chong Yidong]

Ted Zlatanov <tzz@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.

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

[n.mavrogiannopoulos]

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@gnus.org> wrote: 
> 
> LMI> "Roland Winkler" <winkler@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.

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

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

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

regards,
Nikos

bug#15057: 24.3.50; TLS error with reasonably high gnutls-min-prime-bits

[Tassilo Horn]

When TLS support landed and Gnus used it, I frequently had messages like
"the Diffie-Hellman prime has been lowered to XXX bits" for XXX being
256(?) or something like that.  Then I've set

  (setq gnutls-min-prime-bits 2048)

and everything worked smoothly, I got no warning messages, and I felt
more secure.  Well, until today.  When I fired up Gnus today, I got this
error for my Fastmail IMAP account:

--8<---------------cut here---------------start------------->8---
20130809T100721.075> Opening connection to mail.messagingengine.com via tls...
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 mail.messagingengine.com :loglevel 0 :min-prime-bits 2048 :trustfiles (/etc/ssl/certs/ca-certificates.crt) :crlfiles nil :keylist nil :verify-flags nil :verify-error nil :verify-hostname-error nil :callbacks nil)
20130809T100721.380> Unable to open server nnimap+Fastmail due to: GnuTLS error: #<process *nnimap*<1>>, -63
gnutls.c: [0] (Emacs) fatal error: An unexpected TLS handshake packet was received. [100 times]
--8<---------------cut here---------------end--------------->8---

All other accounts still worked just fine.  Lowering
`gnutls-min-prime-bits' to 1024 makes the Fastmail account work again,
too.  So apparently Fastmail doesn't support 2048 bit sized DH primes
anymore (or maybe just today/now) for whatever reason.

Would it be possible to have a new variable
`gnutls-preferred-prime-bits' which is tried first for every connection?
If the server doesn't want to, you'd get a warning and the number of
bits would be lowered, but never below `gnutls-min-prime-bits' which
would still be the hard limit where you get an error.

That way, I could have

  (setq gnutls-min-prime-bits 1024
        gnutls-preferred-prime-bits 2048)

which would successfully use 2048 for all my IMAP connections except for
the Fastmail one today.



In GNU Emacs 24.3.50.1 (x86_64-pc-linux-gnu, GTK+ Version 3.8.2)
 of 2013-08-09 on thinkpad
Bzr revision: monnier@iro.umontreal.ca-20130809011942-ekqcyfmqaf1xicqa
Windowing system distributor `The X.Org Foundation', version 11.0.11402901
System Description:	NAME=Gentoo

Configured using:
 `configure --prefix=/usr --build=x86_64-pc-linux-gnu
 --host=x86_64-pc-linux-gnu --mandir=/usr/share/man
 --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
 --localstatedir=/var/lib --libdir=/usr/lib64 --disable-silent-rules
 --disable-dependency-tracking --program-suffix=-emacs-24-vcs
 --program-transform-name=s/^(emacs)-[0-9].*-././
 --infodir=/usr/share/info/emacs-24-vcs
 --enable-locallisppath=/etc/emacs:/usr/share/emacs/site-lisp
 --with-gameuser=games --without-compress-info
 --with-file-notification=inotify --disable-acl --with-dbus
 --with-gnutls --with-gpm --without-hesiod --without-kerberos
 --without-kerberos5 --with-xml2 --without-selinux --without-wide-int
 --with-sound --with-x --without-ns --without-gconf --with-gsettings
 --with-toolkit-scroll-bars --with-gif --with-jpeg --with-png
 --with-rsvg --with-tiff --with-xpm --with-imagemagick --with-xft
 --with-libotf --with-m17n-flt --with-x-toolkit=gtk3
 GENTOO_PACKAGE=app-editors/emacs-vcs-24.3.9999 EBZR_BRANCH=trunk
 EBZR_REVNO=113772 CFLAGS='-march=native -pipe -g3 -ggdb'
 LDFLAGS='-Wl,-O1 -Wl,--as-needed''

Important settings:
  value of $LC_COLLATE: C
  value of $LC_MONETARY: de_DE.utf8
  value of $LC_NUMERIC: de_DE.utf8
  value of $LC_TIME: de_DE.utf8
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Message

Minor modes in effect:
  gnus-message-citation-mode: t
  diff-auto-refine-mode: t
  mml-mode: t
  global-edit-server-edit-mode: t
  yas-minor-mode: t
  recentf-mode: t
  shell-dirtrack-mode: t
  global-subword-mode: t
  subword-mode: t
  savehist-mode: t
  show-paren-mode: t
  ido-everywhere: t
  minibuffer-depth-indicate-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  auto-fill-function: message-do-auto-fill
  transient-mark-mode: t

Recent input:
l s - m i M-/ . M-q <up> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> M-q <down> <return> <return> b <tab> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <down> <left> <right> <right> <left> SPC SPC S 
o SPC a p p a r e n t l y SPC F a s t m a i l SPC d 
o e s n ' t SPC s u p p o r t SPC 2 0 4 8 SPC b i t 
SPC s i z e d SPC p r i m e s SPC a n y m o r e SPC 
f o r SPC w h a t e v e r SPC r i <backspace> e a s 
o n . <up> <down> <left> <left> <left> <left> <left> 
<left> <left> <left> <left> <left> <left> <left> <left> 
<left> <left> <left> <left> <left> <left> <left> <left> 
SPC ( o r SPC m a y b e SPC j u s t SPC t o d a y / 
n o w ) M-q <down> <down> <down> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <right> <right> <right> <right> <right> 
<right> <right> <backspace> <backspace> <return> <return> 
M-q <down> <down> <right> <right> <right> <right> <right> 
<right> <M-backspace> <M-backspace> <M-backspace> f 
i r s t SPC f o r SPC e v e r y SPC s e r v e r M-q 
<right> <backspace> ? M-q <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> <up> M-x 
r e p o <tab> <return>

Recent messages:
Type C-x 1 to delete the help window.
Auto-saving...done
Mark set
Quit
Auto-saving...done
No expansion found [2 times]
Using try-expand-dabbrev
[yas] snippet expanded.
[yas] Snippet 2 exited.
Auto-saving...done

Load-path shadows:
~/Repos/el/magit/.dir-locals hides ~/Repos/el/highlight-symbol.el/.dir-locals
~/Repos/el/magit/.dir-locals hides ~/Repos/el/gnus/lisp/.dir-locals
~/Repos/el/auctex/lpath hides ~/Repos/el/gnus/lisp/lpath
~/Repos/el/gnus/lisp/hex-util hides /usr/share/emacs/24.3.50/lisp/hex-util
~/Repos/el/gnus/lisp/color hides /usr/share/emacs/24.3.50/lisp/color
~/Repos/el/gnus/lisp/format-spec hides /usr/share/emacs/24.3.50/lisp/format-spec
~/Repos/el/gnus/lisp/password-cache hides /usr/share/emacs/24.3.50/lisp/password-cache
~/Repos/el/gnus/lisp/md4 hides /usr/share/emacs/24.3.50/lisp/md4
~/Repos/el/gnus/lisp/dns-mode hides /usr/share/emacs/24.3.50/lisp/textmodes/dns-mode
~/Repos/el/gnus/lisp/hmac-def hides /usr/share/emacs/24.3.50/lisp/net/hmac-def
~/Repos/el/gnus/lisp/sasl hides /usr/share/emacs/24.3.50/lisp/net/sasl
~/Repos/el/gnus/lisp/dns hides /usr/share/emacs/24.3.50/lisp/net/dns
~/Repos/el/gnus/lisp/ntlm hides /usr/share/emacs/24.3.50/lisp/net/ntlm
~/Repos/el/gnus/lisp/sasl-digest hides /usr/share/emacs/24.3.50/lisp/net/sasl-digest
~/Repos/el/gnus/lisp/dig hides /usr/share/emacs/24.3.50/lisp/net/dig
~/Repos/el/gnus/lisp/hmac-md5 hides /usr/share/emacs/24.3.50/lisp/net/hmac-md5
~/Repos/el/gnus/lisp/tls hides /usr/share/emacs/24.3.50/lisp/net/tls
~/Repos/el/gnus/lisp/sasl-cram hides /usr/share/emacs/24.3.50/lisp/net/sasl-cram
~/Repos/el/gnus/lisp/sasl-ntlm hides /usr/share/emacs/24.3.50/lisp/net/sasl-ntlm
~/Repos/el/gnus/lisp/netrc hides /usr/share/emacs/24.3.50/lisp/net/netrc
~/Repos/el/gnus/lisp/binhex hides /usr/share/emacs/24.3.50/lisp/mail/binhex
~/Repos/el/gnus/lisp/hashcash hides /usr/share/emacs/24.3.50/lisp/mail/hashcash
~/Repos/el/gnus/lisp/uudecode hides /usr/share/emacs/24.3.50/lisp/mail/uudecode
~/Repos/el/gnus/lisp/gnus-undo hides /usr/share/emacs/24.3.50/lisp/gnus/gnus-undo
~/Repos/el/gnus/lisp/qp hides /usr/share/emacs/24.3.50/lisp/gnus/qp
~/Repos/el/gnus/lisp/nnmail hides /usr/share/emacs/24.3.50/lisp/gnus/nnmail
~/Repos/el/gnus/lisp/gnus-srvr hides /usr/share/emacs/24.3.50/lisp/gnus/gnus-srvr
~/Repos/el/gnus/lisp/smiley hides /usr/share/emacs/24.3.50/lisp/gnus/smiley
~/Repos/el/gnus/lisp/mm-encode hides /usr/share/emacs/24.3.50/lisp/gnus/mm-encode
~/Repos/el/gnus/lisp/spam-stat hides /usr/share/emacs/24.3.50/lisp/gnus/spam-stat
~/Repos/el/gnus/lisp/gnus-cite hides /usr/share/emacs/24.3.50/lisp/gnus/gnus-cite
~/Repos/el/gnus/lisp/nnnil hides /usr/share/emacs/24.3.50/lisp/gnus/nnnil
~/Repos/el/gnus/lisp/mm-bodies hides /usr/share/emacs/24.3.50/lisp/gnus/mm-bodies
~/Repos/el/gnus/lisp/nndir hides /usr/share/emacs/24.3.50/lisp/gnus/nndir
~/Repos/el/gnus/lisp/gnus-picon hides /usr/share/emacs/24.3.50/lisp/gnus/gnus-picon
~/Repos/el/gnus/lisp/score-mode hides /usr/share/emacs/24.3.50/lisp/gnus/score-mode
~/Repos/el/gnus/lisp/gnus-demon hides /usr/share/emacs/24.3.50/lisp/gnus/gnus-demon
~/Repos/el/gnus/lisp/gssapi hides /usr/share/emacs/24.3.50/lisp/gnus/gssapi
~/Repos/el/gnus/lisp/gnus-delay hides /usr/share/emacs/24.3.50/lisp/gnus/gnus-delay
~/Repos/el/gnus/lisp/nntp hides /usr/share/emacs/24.3.50/lisp/gnus/nntp
~/Repos/el/gnus/lisp/gnus-spec hides /usr/share/emacs/24.3.50/lisp/gnus/gnus-spec
~/Repos/el/gnus/lisp/mml hides /usr/share/emacs/24.3.50/lisp/gnus/mml
~/Repos/el/gnus/lisp/utf7 hides /usr/share/emacs/24.3.50/lisp/gnus/utf7
~/Repos/el/gnus/lisp/nndiary hides /usr/share/emacs/24.3.50/lisp/gnus/nndiary
~/Repos/el/gnus/lisp/rtree hides /usr/share/emacs/24.3.50/lisp/gnus/rtree
~/Repos/el/gnus/lisp/compface hides /usr/share/emacs/24.3.50/lisp/gnus/compface
~/Repos/el/gnus/lisp/smime hides /usr/share/emacs/24.3.50/lisp/gnus/smime
~/Repos/el/gnus/lisp/starttls hides /usr/share/emacs/24.3.50/lisp/gnus/starttls
~/Repos/el/gnus/lisp/gnus-win hides /usr/share/emacs/24.3.50/lisp/gnus/gnus-win
~/Repos/el/gnus/lisp/gnus-draft hides /usr/share/emacs/24.3.50/lisp/gnus/gnus-draft
~/Repos/el/gnus/lisp/gnus-dup hides /usr/share/emacs/24.3.50/lisp/gnus/gnus-dup
~/Repos/el/gnus/lisp/auth-source hides /usr/share/emacs/24.3.50/lisp/gnus/auth-source
~/Repos/el/gnus/lisp/nnrss hides /usr/share/emacs/24.3.50/lisp/gnus/nnrss
~/Repos/el/gnus/lisp/nndoc hides /usr/share/emacs/24.3.50/lisp/gnus/nndoc
~/Repos/el/gnus/lisp/mm-view hides /usr/share/emacs/24.3.50/lisp/gnus/mm-view
~/Repos/el/gnus/lisp/gnus-cache hides /usr/share/emacs/24.3.50/lisp/gnus/gnus-cache
~/Repos/el/gnus/lisp/gnus-cus hides /usr/share/emacs/24.3.50/lisp/gnus/gnus-cus
~/Repos/el/gnus/lisp/flow-fill hides /usr/share/emacs/24.3.50/lisp/gnus/flow-fill
~/Repos/el/gnus/lisp/nnfolder hides /usr/share/emacs/24.3.50/lisp/gnus/nnfolder
~/Repos/el/gnus/lisp/mml-sec hides /usr/share/emacs/24.3.50/lisp/gnus/mml-sec
~/Repos/el/gnus/lisp/rfc2045 hides /usr/share/emacs/24.3.50/lisp/gnus/rfc2045
~/Repos/el/gnus/lisp/nnheader hides /usr/share/emacs/24.3.50/lisp/gnus/nnheader
~/Repos/el/gnus/lisp/nnoo hides /usr/share/emacs/24.3.50/lisp/gnus/nnoo
~/Repos/el/gnus/lisp/nnvirtual hides /usr/share/emacs/24.3.50/lisp/gnus/nnvirtual
~/Repos/el/gnus/lisp/rfc2231 hides /usr/share/emacs/24.3.50/lisp/gnus/rfc2231
~/Repos/el/gnus/lisp/message hides /usr/share/emacs/24.3.50/lisp/gnus/message
~/Repos/el/gnus/lisp/gnus-sync hides /usr/share/emacs/24.3.50/lisp/gnus/gnus-sync
~/Repos/el/gnus/lisp/gmm-utils hides /usr/share/emacs/24.3.50/lisp/gnus/gmm-utils
~/Repos/el/magit/.dir-locals hides /usr/share/emacs/24.3.50/lisp/gnus/.dir-locals
~/Repos/el/gnus/lisp/nnbabyl hides /usr/share/emacs/24.3.50/lisp/gnus/nnbabyl
~/Repos/el/gnus/lisp/gnus-msg hides /usr/share/emacs/24.3.50/lisp/gnus/gnus-msg
~/Repos/el/gnus/lisp/registry hides /usr/share/emacs/24.3.50/lisp/gnus/registry
~/Repos/el/gnus/lisp/rfc2104 hides /usr/share/emacs/24.3.50/lisp/gnus/rfc2104
~/Repos/el/gnus/lisp/spam hides /usr/share/emacs/24.3.50/lisp/gnus/spam
~/Repos/el/gnus/lisp/nnmairix hides /usr/share/emacs/24.3.50/lisp/gnus/nnmairix
~/Repos/el/gnus/lisp/gnus-mlspl hides /usr/share/emacs/24.3.50/lisp/gnus/gnus-mlspl
~/Repos/el/gnus/lisp/gnus-mh hides /usr/share/emacs/24.3.50/lisp/gnus/gnus-mh
~/Repos/el/gnus/lisp/gnus-ml hides /usr/share/emacs/24.3.50/lisp/gnus/gnus-ml
~/Repos/el/gnus/lisp/nnimap hides /usr/share/emacs/24.3.50/lisp/gnus/nnimap
~/Repos/el/gnus/lisp/mailcap hides /usr/share/emacs/24.3.50/lisp/gnus/mailcap
~/Repos/el/gnus/lisp/gnus-start hides /usr/share/emacs/24.3.50/lisp/gnus/gnus-start
~/Repos/el/gnus/lisp/mm-decode hides /usr/share/emacs/24.3.50/lisp/gnus/mm-decode
~/Repos/el/gnus/lisp/plstore hides /usr/share/emacs/24.3.50/lisp/gnus/plstore
~/Repos/el/gnus/lisp/pop3 hides /usr/share/emacs/24.3.50/lisp/gnus/pop3
~/Repos/el/gnus/lisp/mm-extern hides /usr/share/emacs/24.3.50/lisp/gnus/mm-extern
~/Repos/el/gnus/lisp/sieve-manage hides /usr/share/emacs/24.3.50/lisp/gnus/sieve-manage
~/Repos/el/gnus/lisp/nnir hides /usr/share/emacs/24.3.50/lisp/gnus/nnir
~/Repos/el/gnus/lisp/mml1991 hides /usr/share/emacs/24.3.50/lisp/gnus/mml1991
~/Repos/el/gnus/lisp/nndraft hides /usr/share/emacs/24.3.50/lisp/gnus/nndraft
~/Repos/el/gnus/lisp/mail-source hides /usr/share/emacs/24.3.50/lisp/gnus/mail-source
~/Repos/el/gnus/lisp/gnus-salt hides /usr/share/emacs/24.3.50/lisp/gnus/gnus-salt
~/Repos/el/gnus/lisp/spam-wash hides /usr/share/emacs/24.3.50/lisp/gnus/spam-wash
~/Repos/el/gnus/lisp/nneething hides /usr/share/emacs/24.3.50/lisp/gnus/nneething
~/Repos/el/gnus/lisp/mml-smime hides /usr/share/emacs/24.3.50/lisp/gnus/mml-smime
~/Repos/el/gnus/lisp/deuglify hides /usr/share/emacs/24.3.50/lisp/gnus/deuglify
~/Repos/el/gnus/lisp/mm-partial hides /usr/share/emacs/24.3.50/lisp/gnus/mm-partial
~/Repos/el/gnus/lisp/spam-report hides /usr/share/emacs/24.3.50/lisp/gnus/spam-report
~/Repos/el/gnus/lisp/nnspool hides /usr/share/emacs/24.3.50/lisp/gnus/nnspool
~/Repos/el/gnus/lisp/gnus-gravatar hides /usr/share/emacs/24.3.50/lisp/gnus/gnus-gravatar
~/Repos/el/gnus/lisp/gnus hides /usr/share/emacs/24.3.50/lisp/gnus/gnus
~/Repos/el/gnus/lisp/gnus-dired hides /usr/share/emacs/24.3.50/lisp/gnus/gnus-dired
~/Repos/el/gnus/lisp/mml2015 hides /usr/share/emacs/24.3.50/lisp/gnus/mml2015
~/Repos/el/gnus/lisp/html2text hides /usr/share/emacs/24.3.50/lisp/gnus/html2text
~/Repos/el/gnus/lisp/nnmaildir hides /usr/share/emacs/24.3.50/lisp/gnus/nnmaildir
~/Repos/el/gnus/lisp/ecomplete hides /usr/share/emacs/24.3.50/lisp/gnus/ecomplete
~/Repos/el/gnus/lisp/gnus-ems hides /usr/share/emacs/24.3.50/lisp/gnus/gnus-ems
~/Repos/el/gnus/lisp/nnweb hides /usr/share/emacs/24.3.50/lisp/gnus/nnweb
~/Repos/el/gnus/lisp/gnus-group hides /usr/share/emacs/24.3.50/lisp/gnus/gnus-group
~/Repos/el/gnus/lisp/nnregistry hides /usr/share/emacs/24.3.50/lisp/gnus/nnregistry
~/Repos/el/gnus/lisp/ietf-drums hides /usr/share/emacs/24.3.50/lisp/gnus/ietf-drums
~/Repos/el/gnus/lisp/legacy-gnus-agent hides /usr/share/emacs/24.3.50/lisp/gnus/legacy-gnus-agent
~/Repos/el/gnus/lisp/gnus-bcklg hides /usr/share/emacs/24.3.50/lisp/gnus/gnus-bcklg
~/Repos/el/gnus/lisp/gnus-sum hides /usr/share/emacs/24.3.50/lisp/gnus/gnus-sum
~/Repos/el/gnus/lisp/gnus-icalendar hides /usr/share/emacs/24.3.50/lisp/gnus/gnus-icalendar
~/Repos/el/gnus/lisp/rfc2047 hides /usr/share/emacs/24.3.50/lisp/gnus/rfc2047
~/Repos/el/gnus/lisp/canlock hides /usr/share/emacs/24.3.50/lisp/gnus/canlock
~/Repos/el/gnus/lisp/sieve hides /usr/share/emacs/24.3.50/lisp/gnus/sieve
~/Repos/el/gnus/lisp/gnus-util hides /usr/share/emacs/24.3.50/lisp/gnus/gnus-util
~/Repos/el/gnus/lisp/gnus-fun hides /usr/share/emacs/24.3.50/lisp/gnus/gnus-fun
~/Repos/el/gnus/lisp/nnml hides /usr/share/emacs/24.3.50/lisp/gnus/nnml
~/Repos/el/gnus/lisp/mm-util hides /usr/share/emacs/24.3.50/lisp/gnus/mm-util
~/Repos/el/gnus/lisp/gnus-bookmark hides /usr/share/emacs/24.3.50/lisp/gnus/gnus-bookmark
~/Repos/el/gnus/lisp/gnus-kill hides /usr/share/emacs/24.3.50/lisp/gnus/gnus-kill
~/Repos/el/gnus/lisp/mm-url hides /usr/share/emacs/24.3.50/lisp/gnus/mm-url
~/Repos/el/gnus/lisp/gnus-async hides /usr/share/emacs/24.3.50/lisp/gnus/gnus-async
~/Repos/el/gnus/lisp/nngateway hides /usr/share/emacs/24.3.50/lisp/gnus/nngateway
~/Repos/el/gnus/lisp/sieve-mode hides /usr/share/emacs/24.3.50/lisp/gnus/sieve-mode
~/Repos/el/gnus/lisp/gnus-int hides /usr/share/emacs/24.3.50/lisp/gnus/gnus-int
~/Repos/el/gnus/lisp/gravatar hides /usr/share/emacs/24.3.50/lisp/gnus/gravatar
~/Repos/el/gnus/lisp/gnus-notifications hides /usr/share/emacs/24.3.50/lisp/gnus/gnus-notifications
~/Repos/el/gnus/lisp/gnus-art hides /usr/share/emacs/24.3.50/lisp/gnus/gnus-art
~/Repos/el/gnus/lisp/yenc hides /usr/share/emacs/24.3.50/lisp/gnus/yenc
~/Repos/el/gnus/lisp/nnmh hides /usr/share/emacs/24.3.50/lisp/gnus/nnmh
~/Repos/el/gnus/lisp/mail-prsvr hides /usr/share/emacs/24.3.50/lisp/gnus/mail-prsvr
~/Repos/el/gnus/lisp/gnus-range hides /usr/share/emacs/24.3.50/lisp/gnus/gnus-range
~/Repos/el/gnus/lisp/mm-archive hides /usr/share/emacs/24.3.50/lisp/gnus/mm-archive
~/Repos/el/gnus/lisp/gnus-sieve hides /usr/share/emacs/24.3.50/lisp/gnus/gnus-sieve
~/Repos/el/gnus/lisp/gnus-agent hides /usr/share/emacs/24.3.50/lisp/gnus/gnus-agent
~/Repos/el/gnus/lisp/messcompat hides /usr/share/emacs/24.3.50/lisp/gnus/messcompat
~/Repos/el/gnus/lisp/mm-uu hides /usr/share/emacs/24.3.50/lisp/gnus/mm-uu
~/Repos/el/gnus/lisp/gnus-logic hides /usr/share/emacs/24.3.50/lisp/gnus/gnus-logic
~/Repos/el/gnus/lisp/gnus-topic hides /usr/share/emacs/24.3.50/lisp/gnus/gnus-topic
~/Repos/el/gnus/lisp/gnus-diary hides /usr/share/emacs/24.3.50/lisp/gnus/gnus-diary
~/Repos/el/gnus/lisp/gnus-setup hides /usr/share/emacs/24.3.50/lisp/gnus/gnus-setup
~/Repos/el/gnus/lisp/nnmbox hides /usr/share/emacs/24.3.50/lisp/gnus/nnmbox
~/Repos/el/gnus/lisp/rfc1843 hides /usr/share/emacs/24.3.50/lisp/gnus/rfc1843
~/Repos/el/gnus/lisp/gnus-eform hides /usr/share/emacs/24.3.50/lisp/gnus/gnus-eform
~/Repos/el/gnus/lisp/gnus-vm hides /usr/share/emacs/24.3.50/lisp/gnus/gnus-vm
~/Repos/el/gnus/lisp/nnagent hides /usr/share/emacs/24.3.50/lisp/gnus/nnagent
~/Repos/el/gnus/lisp/mail-parse hides /usr/share/emacs/24.3.50/lisp/gnus/mail-parse
~/Repos/el/gnus/lisp/gnus-html hides /usr/share/emacs/24.3.50/lisp/gnus/gnus-html
~/Repos/el/gnus/lisp/gnus-uu hides /usr/share/emacs/24.3.50/lisp/gnus/gnus-uu
~/Repos/el/gnus/lisp/gnus-registry hides /usr/share/emacs/24.3.50/lisp/gnus/gnus-registry
~/Repos/el/gnus/lisp/gnus-score hides /usr/share/emacs/24.3.50/lisp/gnus/gnus-score
~/Repos/el/gnus/lisp/time-date hides /usr/share/emacs/24.3.50/lisp/calendar/time-date
~/Repos/el/gnus/lisp/parse-time hides /usr/share/emacs/24.3.50/lisp/calendar/parse-time

Features:
(shadow emacsbug flow-fill mm-archive hippie-exp timezone oauth2 json
plstore align url-http url-gw url-auth pp mailalias smtpmail sendmail qp
mule-util sort smiley gnus-cite gnus-async gnus-bcklg gnus-draft gnus-ml
misearch multi-isearch vc-git cus-start cus-load hl-line nndraft nnmh
rot13 utf-7 gnutls network-stream starttls nnimap parse-time tls utf7
netrc nnml nnnil gnus-agent gnus-srvr gnus-score score-mode nnvirtual
gnus-cache gnus-demon nntp spam spam-stat gnus-uu yenc gnus-msg
gnus-gravatar mail-extr gravatar gnus-topic nnir gnus-registry registry
eieio-base th-private highlight-parentheses stratego-mode go-mode-load
greql-mode tg-mode generic preview-latex tex-site auto-loads paredit
magit-cherry magit-bisect magit-log-edit log-edit pcvs-util add-log
magit-key-mode magit diff-mode magit-compat epa-file epa epg rdictcc
google-contacts-message google-contacts-gnus gnus-art mm-uu mml2015
epg-config mm-view mml-smime smime dig gnus-sum nnoo gnus-group
gnus-undo nnmail mail-source gnus-start gnus-spec gnus-int gnus-range
gnus-win gnus gnus-ems gnus-compat nnheader google-contacts url-cache
google-oauth dired-x em-term term ehelp electric esh-opt esh-ext
esh-util highlight-symbol boxquote ecomplete message idna rfc822 mml
mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045
ietf-drums mailabbrev mail-utils gmm-utils mailheader info edit-server
server yasnippet help-mode disp-table noutline outline browse-kill-ring
recentf tree-widget wid-edit helm-nrepl helm-elisp helm-eval helm-info
helm-net browse-url xml url url-proxy url-privacy url-expand url-methods
url-history url-cookie url-domsuf url-util url-parse url-vars mailcap
helm-plugin nrepl ewoc eldoc arc-mode archive-mode etags clojure-mode
derived imenu inf-lisp tramp tramp-compat auth-source eieio byte-opt
bytecomp byte-compile cconv eieio-core gnus-util mm-util mail-prsvr
password-cache tramp-loaddefs trampver shell pcomplete format-spec
helm-buffers helm-grep helm-regexp grep helm-elscreen helm-utils dired
compile comint ansi-color ring helm helm-config helm-aliases easymenu
uniquify multiple-cursors mc-separate-operations rectangular-region-mode
mc-mark-pop mc-mark-more thingatpt mc-cycle-cursors mc-edit-lines
multiple-cursors-core easy-mmode rect iedit help-macro iedit-lib cl-macs
gv cl superword subword saveplace savehist paren ido mb-depth advice
help-fns diminish rx windmove edmacro kmacro cl-loaddefs cl-lib
gnus-load tsdh-dark-theme ack-and-a-half-autoloads boxquote-autoloads
browse-kill-ring-autoloads debbugs-autoloads graphviz-dot-mode-autoloads
highlight-parentheses-autoloads markdown-mode-autoloads
memory-usage-autoloads window-number-autoloads package site-gentoo
time-date tooltip ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
lisp-mode prog-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev minibuffer nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
dbusbind inotify dynamic-setting system-font-setting font-render-setting
move-toolbar gtk x-toolkit x multi-tty emacs)

bug#15057: 24.3.50; TLS error with reasonably high gnutls-min-prime-bits

[Lars Magne Ingebrigtsen]

Tassilo Horn <tsdh@gnu.org> writes:

> When TLS support landed and Gnus used it, I frequently had messages like
> "the Diffie-Hellman prime has been lowered to XXX bits" for XXX being
> 256(?) or something like that.  Then I've set

The fix here is to make that warning go away.  But we're moving to a new
version of gnutls, so nobody has taken the time to twiddle with warning
from the old version of the gnutls library.

> Would it be possible to have a new variable
> `gnutls-preferred-prime-bits' which is tried first for every connection?
> If the server doesn't want to, you'd get a warning and the number of
> bits would be lowered, but never below `gnutls-min-prime-bits' which
> would still be the hard limit where you get an error.

gnutls will try to use as high a number of bits as the server supports,
I think?  So the variables are fine as they are -- they will give you
all the security that the server says that it can provide.

So the warning is kinda semi-bogus.  Or at least ... premature.

-- 
(domestic pets only, the antidote for overdose, milk.)
  No Gnus T-Shirt for sale: http://ingebrigtsen.no/no.php
  and http://lars.ingebrigtsen.no/2013/08/twenty-years-of-september.html

bug#15057: 24.3.50; TLS error with reasonably high gnutls-min-prime-bits

[Ted Zlatanov]

On Sun, 11 Aug 2013 22:03:46 +0200 Lars Magne Ingebrigtsen <larsi@gnus.org> wrote: 

LMI> Tassilo Horn <tsdh@gnu.org> writes:
>> When TLS support landed and Gnus used it, I frequently had messages like
>> "the Diffie-Hellman prime has been lowered to XXX bits" for XXX being
>> 256(?) or something like that.  Then I've set

LMI> The fix here is to make that warning go away.  But we're moving to a new
LMI> version of gnutls, so nobody has taken the time to twiddle with warning
LMI> from the old version of the gnutls library.

See bug#14774 for some info on the warning; I think this is a legitimate
warning.

>> Would it be possible to have a new variable
>> `gnutls-preferred-prime-bits' which is tried first for every connection?
>> If the server doesn't want to, you'd get a warning and the number of
>> bits would be lowered, but never below `gnutls-min-prime-bits' which
>> would still be the hard limit where you get an error.

LMI> gnutls will try to use as high a number of bits as the server supports,
LMI> I think?  So the variables are fine as they are -- they will give you
LMI> all the security that the server says that it can provide.

LMI> So the warning is kinda semi-bogus.  Or at least ... premature.

It's complicated and depends on the specific TLS priority string on the
client and the server's preferences; e.g. ECC seems to negotiate in a
completely different way.  I asked on the gnutls-devel mailing list and
there's just no good answer AFAICT.

Ted

bug#15057: 24.3.50; TLS error with reasonably high gnutls-min-prime-bits

[Lars Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> LMI> gnutls will try to use as high a number of bits as the server supports,
> LMI> I think?  So the variables are fine as they are -- they will give you
> LMI> all the security that the server says that it can provide.
>
> LMI> So the warning is kinda semi-bogus.  Or at least ... premature.
>
> It's complicated and depends on the specific TLS priority string on the
> client and the server's preferences; e.g. ECC seems to negotiate in a
> completely different way.  I asked on the gnutls-devel mailing list and
> there's just no good answer AFAICT.

But we're specifying the minimum prime bits that we accept.  Surely the
client and server will negotiate the maximum possible bits they both
accept?

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

bug#15057: 24.3.50; TLS error with reasonably high gnutls-min-prime-bits

[Ted Zlatanov]

On Thu, 30 Jan 2014 16:46:43 -0800 Lars Ingebrigtsen <larsi@gnus.org> wrote: 

LI> Ted Zlatanov <tzz@lifelogs.com> writes:
LMI> gnutls will try to use as high a number of bits as the server supports,
LMI> I think?  So the variables are fine as they are -- they will give you
LMI> all the security that the server says that it can provide.
>> 
LMI> So the warning is kinda semi-bogus.  Or at least ... premature.
>> 
>> It's complicated and depends on the specific TLS priority string on the
>> client and the server's preferences; e.g. ECC seems to negotiate in a
>> completely different way.  I asked on the gnutls-devel mailing list and
>> there's just no good answer AFAICT.

LI> But we're specifying the minimum prime bits that we accept.  Surely the
LI> client and server will negotiate the maximum possible bits they both
LI> accept?

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.

The suggestion from Nikos was to make the above the *default* for all
connections.  I'm OK with that, if it works for you.

Ted

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

[Ted Zlatanov]

On Fri, 18 May 2012 04:38:01 -0700 (PDT) n.mavrogiannopoulos@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@gnus.org> wrote: 
>> 
LMI> "Roland Winkler" <winkler@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

bug#15057: 24.3.50; TLS error with reasonably high gnutls-min-prime-bits

[Lars Ingebrigtsen]

Ted Zlatanov <tzz@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.

But aren't there lots of (or some) servers that only supports DHE and
not ECDHE?

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

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

[Roland Winkler]

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.

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

[Nikos Mavrogiannopoulos]

On Mon, Feb 10, 2014 at 4:06 AM, Roland Winkler <winkler@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

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

[Ted Zlatanov]

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

NM> On Mon, Feb 10, 2014 at 4:06 AM, Roland Winkler <winkler@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@gnus.org> wrote: 

LI> Ted Zlatanov <tzz@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

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

[Lars Ingebrigtsen]

Ted Zlatanov <tzz@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/

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

[Nikos Mavrogiannopoulos]

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

bug#16253: 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).

[Ted Zlatanov]

On Mon, 10 Feb 2014 21:09:25 -0800 Lars Ingebrigtsen <larsi@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

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

[Roland Winkler]

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

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

[Ted Zlatanov]

On Tue, 11 Feb 2014 16:49:06 -0600 "Roland Winkler" <winkler@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

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

[Lars Ingebrigtsen]

Ted Zlatanov <tzz@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/

bug#15057: 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).

[Lars Ingebrigtsen]

Ted Zlatanov <tzz@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/

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)

[Ted Zlatanov]

(I love how mangled the subject line became)

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

LI> Ted Zlatanov <tzz@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

bug#15057: 24.3.50; TLS error with reasonably high gnutls-min-prime-bits

[Lars Magne Ingebrigtsen]

Tassilo Horn <tsdh@gnu.org> writes:

> When TLS support landed and Gnus used it, I frequently had messages like
> "the Diffie-Hellman prime has been lowered to XXX bits" for XXX being
> 256(?) or something like that.  Then I've set
>
>   (setq gnutls-min-prime-bits 2048)
>
> and everything worked smoothly, I got no warning messages, and I felt
> more secure.  Well, until today.  When I fired up Gnus today, I got this
> error for my Fastmail IMAP account:
>
> 20130809T100721.075> Opening connection to mail.messagingengine.com via tls...
> gnutls.c: [0] (Emacs) fatal error: The Diffie-Hellman prime sent by the server is not acceptable (not long enough).

That's what you asked it to do, so it's not a bug.  However, the NSM
just got a Diffie-Hellman check, so that can be used instead.  So I'm
closing this bug report.

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