GNU bug report logs - #15057
24.3.50; TLS error with reasonably high gnutls-min-prime-bits

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 15057 in the body.
You can then email your comments to 15057 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: Tassilo Horn <tsdh <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; TLS error with reasonably high gnutls-min-prime-bits
Date: Fri, 09 Aug 2013 10:52:14 +0200

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

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

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: Tassilo Horn <tsdh <at> gnu.org>
Cc: 15057 <at> debbugs.gnu.org
Subject: Re: bug#15057: 24.3.50;
 TLS error with reasonably high gnutls-min-prime-bits
Date: Sun, 11 Aug 2013 22:03:46 +0200

Tassilo Horn <tsdh <at> 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

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

From: Ted Zlatanov <tzz <at> lifelogs.com>
To: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
Cc: 15057 <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
Date: Mon, 07 Oct 2013 18:27:58 -0400

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

LMI> Tassilo Horn <tsdh <at> 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

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: 15057 <at> debbugs.gnu.org
Cc: Tassilo Horn <tsdh <at> gnu.org>
Subject: Re: bug#15057: 24.3.50;
 TLS error with reasonably high gnutls-min-prime-bits
Date: Thu, 30 Jan 2014 16:46:43 -0800

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

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

From: Ted Zlatanov <tzz <at> lifelogs.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 15057 <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
Date: Sun, 09 Feb 2014 21:15:48 -0500

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

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

Message #20 received at 15057 <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 #23 received at 15057 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: 15057 <at> debbugs.gnu.org
Cc: Tassilo Horn <tsdh <at> gnu.org>
Subject: Re: bug#15057: 24.3.50;
 TLS error with reasonably high gnutls-min-prime-bits
Date: Sun, 09 Feb 2014 18:58:34 -0800

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.

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/

Message #26 received at 15057 <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 #29 received at 15057 <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 #32 received at 15057 <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 #35 received at 15057 <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 #38 received at 15057 <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 #41 received at 15057 <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 #44 received at 15057 <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 #47 received at 15057 <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 #50 received at 15057 <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 #53 received at 15057 <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

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

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: Tassilo Horn <tsdh <at> gnu.org>
Cc: 15057 <at> debbugs.gnu.org
Subject: Re: bug#15057: 24.3.50;
 TLS error with reasonably high gnutls-min-prime-bits
Date: Mon, 08 Dec 2014 20:43:40 +0100

Tassilo Horn <tsdh <at> 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

Previous Next

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