Kalle Olavi Niemitalo <[email protected]> writes: > Simon Josefsson <[email protected]> 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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
