Petr Baudis <pa...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org