„Błąd błędu parsowania tlsext” na dużym zatwierdzeniu do SVN przez Apache, Gentoo

Dzieje się tak tylko w przypadku dużego zatwierdzenia (co powoduje niepowodzenie zatwierdzenia):

Sekcja rewelacyjna z konfiguracji hosta wirtualnego w Apache

   <LimitExcept POBIERZ RAPORT O OPCJACH OPCJI>
      Wymagaj ważnego użytkownika
   </LimitExcept>
   Dav svn
   SVNPath / home / svn /

Zatwierdź wynik:

Przesyłanie danych pliku .............................. svn: Niepowodzenie zatwierdzenia
(szczegóły poniżej):
svn: PUT z
„/!svn/wrk/48583f7d-0e01-410d-8941-33d2ba3574b4/WAP/.../htdocs/images/rt.gif”:
Negocjacja SSL nie powiodła się: Błąd SSL: parsuj tlsext (https: // ...)

Znalazłem odniesienia do tego tutaj: http://code.google.com/p/support/issues/detail?id=1395

stwierdzając, że OpenSSL powinien zostać skompilowany z rozszerzeniem TLS, ale w moim przypadku nie powoduje błędu na początku, tylko przy dużych zmianach.

Jakieś pomysły? Dzięki

Nie spotkałem się z tym problemem, ale spędziłem trochę czasu na googlowaniu i odkryłem, że mógł zostać wprowadzony w Apache 2.2.12 lub 13. Sugeruje się, że obniżenie wersji do 2.2.11 może to naprawić, a także ustawienie SSLProtocol - ALL + SSLv2 + SSLv3 w konfiguracji Apache. Żaden z nich nie wydawał się ostateczny. Powodzenia! Mam nadzieję, że znajdziesz rozwiązanie.

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

AKTUALIZACJA

Po przeczytaniu wątku http-dev na ten temat, zarchiwizowanego pod adresem http://www.gossamer-threads.com/lists/apache/dev/375633 , wygląda na to, że przyczyną tego problemu jest błąd w bibliotece OpenSSL po stronie klienta w dotyczy sposobu obsługi biletów / identyfikatorów SSL, co wyjaśnia, dlaczego błąd nie pojawia się natychmiast, ale zajmuje kilka sekund lub minut. Ta rozdzielczość została ustalona 2 listopada, trzy dni przed wydaniem OpenSSL 0.9.8l. Wątek nie określa wprost, czy / kiedy poprawka została zastosowana w OpenSSL, ale myślę, że możemy spodziewać się, że zostanie ona naprawiona na 0,9,8 m, co moim zdaniem obejmuje ten wpis w dzienniku zmian m-beta:

*) Poprawki do obsługi wznawiania sesji bezstanowych. Użyj initial_ctx podczas wystawiania i próby odszyfrowania biletów w przypadku, gdy zmieniło się to podczas obsługi nazwy serwera. Użyj identyfikatora sesji o niezerowej długości podczas próby wznowienia sesji bezstanowej: pozwala to ustalić, czy wznowienie nastąpiło natychmiast po otrzymaniu serwera hello (kilka miejsc w OpenSSL subtelnie to przyjmuje) zamiast później w trakcie uzgadniania.

ORYGINALNY POCZTA

Mam podobne problemy z Apache-2.2.14 na Gentoo. Dla porównania, oto moje flagi USE:

[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

Dzieje się tak w przypadku dowolnej kombinacji protokołu SSLProtocol z TLSv1dołączonym

Jeśli dostosuję mój SSLProtocoldo usunięcia TLSv1, otrzymuję nowy błąd:

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)

Dzieje się tak mniej więcej w tym samym czasie, gdy zamiast tego pojawia się błąd „parsuj tlsext”.

Ten problem jest najbardziej prawdopodobny z powodu używania wielu hostów wirtualnych z obsługą SSL w Apache httpd 2.2.12 - 2.2.14 i OpenSSL 0.9.8f - 0.9.8l.

Następująca łatka wydaje mi się rozwiązać problem.