10

This happens only on large commit (resulting in a failed commit):

Revelant section from virtual host config in Apache

 <LimitExcept GET PROPFIND OPTIONS REPORT> Require valid-user </LimitExcept> Dav svn SVNPath /home/svn/

Commit result:

 Transmitting file data ..............................svn: Commit failed (details follow): svn: PUT of '/!svn/wrk/48583f7d-0e01-410d-8941-33d2ba3574b4/WAP/.../htdocs/images/rt.gif': SSL negotiation failed: SSL error: parse tlsext (https://...)

I found references to it here: http://code.google.com/p/support/issues/detail?id=1395

stating that OpenSSL should be compiled with TLS extension, but in my case, it doesn't error out at the start, just on large commits.

Any ideas? Thanks

Improve this question
1
  • is there an apache httpd bugtracker ticket for this bug? Commented Jan 6, 2010 at 23:01

3 Answers 3

Reset to default
7

I haven't experienced this issue, but I spent a while googling around and found that it may have been introduced in Apache 2.2.12 or 13. It is suggested that downgrading to 2.2.11 may fix it, as well as setting SSLProtocol -ALL +SSLv2 +SSLv3 in your Apache config. Neither one seemed definitive. Good luck! Hope you find a solution.

http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2393204

Improve this answer
4
  • Adding SSLProtocol -ALL +SSLv2 +SSLv3 worked for me as well. Commented Feb 10, 2011 at 20:02
  • For what it is worth, I had the same problem and adding SSLProtocol -ALL +SSLv2 +SSLv3 as mentioned above fixed this issue for me. Commented Feb 10, 2011 at 20:02
  • I was having this same problem trying to connect from Ruby 1.9.3. Ruby 1.9.2 wasn't a problem for whatever reason. And the error happened immediately when using a client certificate. Changing my config from SSLProtocol all -SSLv2 to SSLProtocol ALL -SSLv2 -TLSv1 fixed the issue for me. Commented Apr 9, 2012 at 22:34
  • 1
    Please note that SSLv2 has been deprecated since 1996 Commented Dec 28, 2012 at 17:50
5

UPDATE

After reading the http-dev thread about this issue, archived at http://www.gossamer-threads.com/lists/apache/dev/375633 , it seems this issue is caused by a bug in the client-side OpenSSL library in regards to how SSL Tickets / IDs are handled, which explains why the error does not occur immediately, but takes a few seconds to minutes. This resolution was determined on Nov 2, three days before OpenSSL 0.9.8l came out. The thread does not explicitly state if/when the fix was applied to OpenSSL, but I think it's something we can anticipate being fixed in 0.9.8m, which I believe is covered by this entry in the m-beta changelog:

*) Fixes to stateless session resumption handling. Use initial_ctx when issuing and attempting to decrypt tickets in case it has changed during servername handling. Use a non-zero length session ID when attempting stateless session resumption: this makes it possible to determine if a resumption has occurred immediately after receiving server hello (several places in OpenSSL subtly assume this) instead of later in the handshake.

ORIGINAL POST

I'm experiencing similar issues on Apache-2.2.14 on Gentoo. For reference, here's my USE flags:

[ebuild R ] dev-libs/openssl-0.9.8l-r2 USE="zlib -bindist -gmp -kerberos -sse2 -test" 4,082 kB [ebuild R ] www-servers/apache-2.2.14-r1 USE="ssl -debug -doc -ldap (-selinux) -static -suexec -threads" APACHE2_MODULES="actions alias auth_basic auth_digest authn_dbd authn_default authn_file authz_default authz_groupfile authz_host authz_user autoindex dav dav_fs dav_lock dbd deflate dir env expires headers include info log_config logio mime mime_magic negotiation proxy proxy_balancer proxy_connect proxy_http rewrite setenvif status unique_id userdir -asis -authn_alias -authn_anon -authn_dbm -authz_dbm -authz_owner -cache -cern_meta -charset_lite -disk_cache -dumpio -ext_filter -file_cache -filter* -ident -imagemap -log_forensic -mem_cache -proxy_ajp -proxy_ftp -speling -substitute -usertrack* -version -vhost_alias" APACHE2_MPMS="prefork -event -itk -peruser -worker" 5,088 kB [ebuild R ] net-misc/neon-0.29.0 USE="expat nls ssl zlib -doc -gnutls -kerberos -libproxy -pkcs11" LINGUAS="-cs -de -fr -ja -nn -pl -ru -tr -zh_CN" 859 kB [ebuild R ] dev-util/subversion-1.6.6 USE="apache2 bash-completion dso nls perl python ruby webdav-neon -berkdb -ctypes-python -debug -doc -emacs -extras -gnome-keyring -java -sasl -test -vim-syntax -webdav-serf" 5,384 kB

This occurs with any combination of SSLProtocol with TLSv1 included

If I adjust my SSLProtocol to remove TLSv1, I get a new error:

svn: PUT of '/!svn/wrk/0b9f5a96-15aa-11df-ad6a-0f71b873281b/project/trunk/path/btn_Cancel.gif': SSL handshake failed: SSL error: bad decompression (https://svn.mudbugmedia.com)

This occurs at approximately the same time that I'd encounter the "parse tlsext" error instead.

Improve this answer
1
  • Upgrading my SVN client from 1.6 to 1.7 solved the "parse tlsext" issue for me, supporting the suggestion by @gabe-martin-dempesy that "this issue is caused by a bug in the client-side OpenSSL library" Commented Dec 28, 2012 at 17:48
0

This issue is most propably because of using multiple SSL enabled VirtualHosts in Apache httpd 2.2.12 - 2.2.14 and OpenSSL 0.9.8f - 0.9.8l .

The following patch seems to solve the issue for me.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.