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

Karolis T.
  • 2,709
  • 7
  • 32
  • 45

3 Answers3

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

Jeff Snider
  • 3,252
  • 17
  • 17
  • Adding **SSLProtocol -ALL +SSLv2 +SSLv3** worked for me as well. –  Feb 10 '11 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. – Adam Carr Feb 10 '11 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. – aNoble Apr 09 '12 at 22:34
  • 1
    Please note that [SSLv2 has been deprecated since 1996](http://www.gnu.org/software/gnutls/manual/html_node/On-SSL-2-and-older-protocols.html) – Jared Beck Dec 28 '12 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.

Gabe Martin-Dempesy
  • 410
  • 5
  • 11
  • 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" – Jared Beck Dec 28 '12 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.