Bug#528661: elinks eternally stuck in SSL negotiation phase
Kalle Olavi Niemitalo k...@iki.fi writes: Simon Josefsson si...@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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528661: elinks eternally stuck in SSL negotiation phase
Simon Josefsson si...@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? pgpelqi1gR5zY.pgp Description: PGP signature
Bug#528661: elinks eternally stuck in SSL negotiation phase
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? Petr Pasky Baudis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528661: elinks eternally stuck in SSL negotiation phase
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
Bug#528661: elinks eternally stuck in SSL negotiation phase
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. Rather than closing this bug, we could re-assign the problem back to elinks as a wishlist bug to provide better error handling in this situation. A naive solution would be to disable TLS1.1 in elinks. Here is a patch against elinks to accomplish that. diff --git a/src/network/ssl/ssl.c b/src/network/ssl/ssl.c index 7ae3a04..81db379 100644 --- a/src/network/ssl/ssl.c +++ b/src/network/ssl/ssl.c @@ -278,7 +278,7 @@ init_ssl_connection(struct socket *socket) return S_SSL_ERROR; } - gnutls_set_default_priority(*state); + gnutls_priority_set_direct (*state, NORMAL:-VERS-TLS1.1, NULL); gnutls_handshake_set_private_extensions(*state, 1); gnutls_cipher_set_priority(*state, cipher_priority); gnutls_kx_set_priority(*state, kx_priority); /Simon [1] http://savannah.gnu.org/support/?106776 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528661: elinks eternally stuck in SSL negotiation phase
Package: elinks Version: 0.12~pre3-2 Severity: important When accessing https://bugzilla.novell.com/, ELinks gets stuck in the SSL negotiation phase forever. Links2 handles the page fine. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.29-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=cs_CZ.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages elinks depends on: ii elinks-data 0.12~pre3-2 advanced text-mode WWW browser - d ii libbz2-1.0 1.0.5-1 high-quality block-sorting file co ii libc62.9-4 GNU C Library: Shared libraries ii libcomerr2 1.41.3-1common error description library ii libexpat12.0.1-4 XML parsing C library - runtime li ii libfsplib0 0.9-1 FSP v2 protocol stack library - sh ii libgnutls26 2.6.6-1 the GNU TLS library - runtime libr ii libgpm2 1.20.4-3.2 General Purpose Mouse - shared lib ii libgssapi-krb5-2 1.6.dfsg.4~beta1-13 MIT Kerberos runtime libraries - k ii libidn11 1.14-3 GNU Libidn library, implementation ii libk5crypto3 1.6.dfsg.4~beta1-13 MIT Kerberos runtime libraries - C ii libkrb5-31.6.dfsg.4~beta1-13 MIT Kerberos runtime libraries ii liblua50 5.0.3-3 Main interpreter library for the L ii liblualib50 5.0.3-3 Extension library for the Lua 5.0 ii libmozjs1d 1.9.0.7-1 The Mozilla SpiderMonkey JavaScrip ii libperl5.10 5.10.0-19 Shared Perl library ii libruby1.8 1.8.7.72-3.1Libraries necessary to run Ruby 1. ii libtre4 0.7.5-2 regexp matching library with appro ii zlib1g 1:1.2.3.3.dfsg-13 compression library - runtime elinks recommends no packages. Versions of packages elinks suggests: ii elinks-doc 0.12~pre3-2 advanced text-mode WWW browser - d -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528661: elinks eternally stuck in SSL negotiation phase
I'm sorry, I was too quick to file a bug - after waiting several minutes initially, the SSL negotiation phase finished; on subsequent requests on the site, the delay is also longer than usual, but acceptable. Still, this is quite an inconvience and should be fixed; links2 serves me the page immediately. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#528661: elinks eternally stuck in SSL negotiation phase
Hi Petr, On 09/05/14 16:02 +0200, Petr Baudis said ... I'm sorry, I was too quick to file a bug - after waiting several minutes initially, the SSL negotiation phase finished; on subsequent requests on the site, the delay is also longer than usual, but acceptable. Still, this is quite an inconvience and should be fixed; links2 serves me the page immediately. I will check if this is this because elinks uses gnutls and links2 uses openssl. Giridhar -- Y Giridhar Appaji Nag | http://appaji.net/ signature.asc Description: Digital signature
