On 2015-05-15 Kurt Roeckx <k...@roeckx.be> wrote: > On Fri, May 15, 2015 at 07:16:37PM +0200, Andreas Metzler wrote: [...] >> GnuTLS has become more picky when evaluating priority strings and >> lynx is using an incorrect one.
> Can you explain a little more what's wrong with the priority > string? (I have no idea what the current value is.) Hello, the whole issue first showed up as bug report against gnutls <https://bugs.debian.org/784430> (I have kept it there for the time being to avoid duplicates), so I can sum up the the key points nicely: The actual string is NONE:+VERS-SSL3.0:+VERS-TLS1.2:+VERS-TLS1.1:+VERS-TLS1.0:+AES-256-GCM:+AES-128-GCM:+AES-256-CBC:+AES-128-CBC:+CAMELLIA-256-CBC:+CAMELLIA-128-CBC:+3DES-CBC:+COMP-NULL:+DHE-RSA:+RSA:+DHE-DSS:+SHA1:+MD5 (lynx -trace to the rescue ;-) As it starts up with NONE it implicitely disables SIGN-* (Signature algorithms), CURVE-* (Elliptic curves) and CTYPE-* (Certificate type). The absence of SIGN-* breaks any TLS1.2 connections. (Do not ask me why, Nikos Mavrogiannopoulos said so [1], experimenting with gnutls-bin --priority=NORMAL:-SIGN-ALL and --priority=NORMAL:-VERS-TLS1.2:-SIGN-ALL shows he is right.) [...] > With lynx it's also sending an other cipher list, which doesn't > include any GCM based cipher suite. It should probably use some > default string instead. [...] That is exactly what lynx-cur/experimental does. I read Thomas Dickey's (lynx upstream) comment "simpler settings sounds like an improvement..." as agreement. ;-) http://lists.nongnu.org/archive/html/lynx-dev/2015-05/msg00014.html cu Andreas [1] http://article.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/8152 -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
