After upgrading to Apache 2.2.14-r1 from Apache 2.2.11, a subversion repository hosted by it began returning the following error mid-way through larger commits: '/!svn/wrk/48583f7d-0e01-410d-8941-33d2ba3574b4/WAP/.../htdocs/images/rt.gif': SSL negotiation failed: SSL error: parse tlsext (https://...) This seems to be commonly reported as an issue with Apache 2.2.12 - 2.2.14. Many people struggling with this have suggested removing TLSv1 from Apache's SSLProtocol. However, this results in the following different 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://...) The recommend work-around to this error seems to be to add TLSv1 back to your SSLProtocol, which returns us back to the original error. Some references include this note: > Moreover I found out that this problem only occurs if there are at least two > virtual hosts served using SSL on the same IP address (<VirtualHost *:443>) > by Apache (distinguish by their "ServerName"). In this case with my configuration, I have multiple VirtualHosts sharing the same IP:Port combination as they are using the same wildcard certificate with different hostnames. Here are the versions and Gentoo USE (compile) flags of all the relevant components on my repository's server: [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 References: * http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2382623 * http://code.commongroove.com/archive/2009/09/25/apachesubversion-ssl-negotiation-failed-ssl-error-parse-tlsext.aspx * http://serverfault.com/questions/44470/ssl-error-parse-tlsext-on-large-commit-to-svn-via-apache-gentoo * http://old.nabble.com/parse-tlsext-bug-td24802438.html
Reading more documentation, it seems obvious, based on the timing and the "tlsext" in the error message, that this is related to ServerNameIndication introduced in Apache 2.2.12 (which is the starting version for most of the reports I've seen). Here's a few more notes with SNI in mind: * Both the clients and the server's OpenSSL have SNI enabled, verified by visiting an SNI test site via curl, linked against the same openssl as subversion: https://sni.velox.ch/ * Putting the Subversion repository on its own dedicated IP/port slightly improved the scenario; instead of erroring about 30 seconds into a large commit, it now does so 5-6 minutes in. * Completely removing the "NameVirtualHost 10.10.10.15:443" line from my configuration (and appropriately adjusting the SSL VirtualHosts down to one vhost per ip/port) has no effect * Doing both of the above with TLSv1 removed from SSLProtocol still results in the "bad decompression" error ~20 seconds into the commit. * In all of the above, IE6 (which lacks SNI support) can access the subversion repository URL without issue. * Turning "SSLStrictSNIVHostCheck on" has no effect on subversion. The error still occurs as normal, and no warnings are displayed to the client or in apache's logs. IE6 gets a 403 and a warning in the log, though. Based on this, it doesn't seem like the apache configuration is the issue here. Also, after reading the thread from the http-dev mailing list archived at http://www.gossamer-threads.com/lists/apache/dev/375633 , it seems that the root cause for this is an issue with SSL ticket / session id handling in the client library. The conclusion is that it will be fixed in the OpenSSL package.