Bug#528661: elinks eternally stuck in SSL negotiation phase

[Simon Josefsson]

Petr Baudis <pasky at ucw.cz> writes:

> On Thu, May 28, 2009 at 11:38:27PM +0200, Simon Josefsson wrote:
>> The problem is a buggy server, see the upstream bug about this [1], so I
>> don't see anything that can/should be changed in GnuTLS.
>
> Then why do Firefox and applications using OpenSSL have no trouble
> talking to the server?

I believe they only work when they do not attempt to negotiate TLS 1.1.

I see in elinks/src/network/ssl/ssl.c:

	context = SSL_CTX_new(SSLv23_client_method());

The man page reads:

       SSLv23_method(void), SSLv23_server_method(void),
       SSLv23_client_method(void)
           A TLS/SSL connection established with these methods will understand
           the SSLv2, SSLv3, and TLSv1 protocol. A client will send out SSLv2
           client hello messages and will indicate that it also understands
           SSLv3 and TLSv1. A server will understand SSLv2, SSLv3, and TLSv1
           client hello messages. This is the best choice when compatibility
           is a concern.

So if you don't care about TLS 1.1 support, and by using
SSLv23_client_method that seems to be the intention (or?), then you
probably want to ask GnuTLS to disable TLS 1.1 too.

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.  It doesn't belong in
GnuTLS, since GnuTLS does not establish the connection.

/Simon