[pkg-lynx-maint] Bug#785383: Bug#785383: Bug#785383: lynx: Can't connect to (some) https sites

[Andreas Metzler]

On 2015-05-15 Kurt Roeckx <kurt at 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'