Bug#528661: elinks eternally stuck in SSL negotiation phase

[Kalle Olavi Niemitalo]

Simon Josefsson <simon at josefsson.org> writes:

> Firefox may have some logic to re-try the connection using a lower TLS
> version when a higher TLS version did not work out well -- that logic
> would be useful to duplicate in elinks too.

ELinks already has logic to switch to SSLv3 only.
See ssl_set_no_tls in elinks/src/network/ssl/socket.c:
http://repo.or.cz/w/elinks.git?a=blob;f=src/network/ssl/socket.c;h=45b4b4a8887d2b54c12321a107c1b5a5d7382e85;hb=3801698ff1ddfa2aa94466e90851e496d95156c0

If the SSLv3 connection then succeeds, ELinks uses SSLv3 for
later connections to the same server too.  This corresponds to
Pasky's report that only the first connection was slow.  ELinks
doesn't save this blacklist to a file though, so it is lost when
ELinks is restarted.

Can you do something in GNUTLS to make the TLSv1.1 connection
fail sooner?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnutls-maint/attachments/20090530/1a34cea7/attachment.pgp>