"SSL error parse tlsext" bei großem Commit für SVN über Apache, Gentoo

Dies geschieht nur bei einem großen Commit (was zu einem fehlgeschlagenen Commit führt):

Offenbarer Abschnitt aus der Konfiguration des virtuellen Hosts in Apache

   <LimitExcept GET PROPFIND OPTIONS REPORT>
      Benötigen Sie einen gültigen Benutzer
   </ LimitExcept>
   Dav svn
   SVNPath / home / svn /

Ergebnis festschreiben:

Übertragen von Dateidaten .............................. svn: Commit fehlgeschlagen
(Details folgen):
svn: PUT von
'/!svn/wrk/48583f7d-0e01-410d-8941-33d2ba3574b4/WAP/.../htdocs/images/rt.gif':
SSL-Aushandlung fehlgeschlagen: SSL-Fehler: parse tlsext (https: // ...)

Ich habe hier Verweise darauf gefunden: http://code.google.com/p/support/issues/detail?id=1395

Daraus geht hervor, dass OpenSSL mit der TLS-Erweiterung kompiliert werden sollte, aber in meinem Fall tritt es beim Start nicht auf, nur bei großen Commits.

Irgendwelche Ideen? Vielen Dank

Ich habe dieses Problem noch nicht erlebt, habe aber eine Weile gegoogelt und festgestellt, dass es möglicherweise in Apache 2.2.12 oder 13 eingeführt wurde. Es wird empfohlen, es durch ein Downgrade auf 2.2.11 zu beheben und SSLProtocol festzulegen. ALL + SSLv2 + SSLv3 in Ihrer Apache-Konfiguration. Keiner schien endgültig zu sein. Viel Glück! Ich hoffe, Sie finden eine Lösung.

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

AKTUALISIEREN

Nach dem Lesen des http-dev-Threads zu diesem Problem, der unter http://www.gossamer-threads.com/lists/apache/dev/375633 archiviert wurde , scheint dieses Problem durch einen Fehler in der clientseitigen OpenSSL-Bibliothek in verursacht zu sein in Bezug auf den Umgang mit SSL-Tickets / IDs, was erklärt, warum der Fehler nicht sofort auftritt, sondern einige Sekunden bis Minuten dauert. Diese Auflösung wurde am 2. November, drei Tage vor dem Erscheinen von OpenSSL 0.9.8l, festgelegt. Der Thread gibt nicht explizit an, ob / wann der Fix auf OpenSSL angewendet wurde, aber ich denke, wir können davon ausgehen, dass er in 0,9,8 m behoben wird, was meines Erachtens durch diesen Eintrag im m-beta-Änderungsprotokoll abgedeckt wird:

*) Behebt die Behandlung der Wiederaufnahme der Sitzung ohne Status. Verwenden Sie initial_ctx, wenn Sie Tickets ausstellen und versuchen, diese zu entschlüsseln, falls sie sich während der Behandlung von Servernamen geändert haben. Verwenden Sie eine Sitzungs-ID ungleich Null, wenn Sie versuchen, die Sitzung ohne Status wieder aufzunehmen. Auf diese Weise können Sie feststellen, ob eine Wiederaufnahme unmittelbar nach dem Empfang des Server-Hallo erfolgt ist (mehrere Stellen in OpenSSL nehmen dies subtil an), anstatt später im Handshake.

ORIGINAL POST

Ich habe ähnliche Probleme mit Apache-2.2.14 unter Gentoo. Als Referenz sind hier meine 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

Dies tritt bei jeder Kombination von SSLProtocol mit TLSv1eingeschlossen auf

Wenn ich meine SSLProtocolzum Entfernen TLSv1anpasse, wird eine neue Fehlermeldung angezeigt:

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)

Dies geschieht ungefähr zur gleichen Zeit, zu der stattdessen der Fehler "parse tlsext" auftritt.

Dieses Problem ist höchstwahrscheinlich auf die Verwendung mehrerer SSL-fähiger VirtualHosts in Apache httpd 2.2.12 - 2.2.14 und OpenSSL 0.9.8f - 0.9.8l zurückzuführen.

Der folgende Patch scheint das Problem für mich zu lösen.