On Tue, Mar 11, 2014 at 11:27:24PM +0100, Alessandro Ghedini wrote: > So, the problem is not gnutls (or not *just* gnutls), but the fact that the > server doesn't seem to support TLSv1,
That is likely related to this Apache config setting: # Work around "SSL negotiation failed: SSL error: parse tlsext"; see e.g. # http://serverfault.com/questions/44470/ssl-error-parse-tlsext-on-large-commit-to-svn-via-apache-gentoo SSLProtocol -ALL +SSLv3 Unfortunately I can't lose this altogether because I have to support old clients that seem to need it. However, I confirm that disabling this setting works around the git/curl/gnutls problem. > and that for some reason the TLS renegotiation fails. > > I can reproduce this with OpenSSL too, by forcing TLSv1: > > % openssl s_client -host <host> -port 443 -tls1 > CONNECTED(00000003) > 139971996092048:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version > number:s3_pkt.c:337: > > And gnutls-cli: > > % gnutls-cli <host> -p 443 --priority > "NORMAL:-VERS-TLS-ALL:+VERS-TLS1.0:%COMPAT" > [...] > *** Fatal error: A record packet with illegal version was received. > *** Handshake has failed > GnuTLS error: A record packet with illegal version was received. > > Now, why does libcurl fails while gnutls-cli (built against libgnutls26) does > not (not by default, anyway)? That may be a bug in libcurl, I'll look into > this > later. Thanks! Andras -- If at first you don't succeed, skydiving is not for you. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
