Bug#528661: elinks eternally stuck in SSL negotiation phase

[Simon Josefsson]

Kalle Olavi Niemitalo <kon at iki.fi> writes:

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

Ah, that's good.

> Can you do something in GNUTLS to make the TLSv1.1 connection
> fail sooner?

I can't think of anything, but ideas welcome.  The problem is that the
server never replies to the initial packet, and does not shut down the
TCP connection.  So GnuTLS has no way of knowing that the server is
buggy.  And GnuTLS cannot re-connect to the server, since it is the
application that is responsible for managing the connections.

One solution would be for elinks to first try TLS 1.1, and if there is
no response within 5 seconds, re-try the connection using TLS 1.0.

However, for a web application, it seems TLSv1.1 is of marginal use, so
just ignoring it until people reports that as a problem may be the
simplest approach.  It appears to be what Mozilla does.

/Simon