"SSL error parse tlsext" en un gran commit a SVN a través de Apache, Gentoo

Esto sucede solo en la confirmación grande (lo que resulta en una confirmación fallida):

Sección revelante de la configuración del host virtual en Apache

   <Límite, excepto OBTENER INFORME DE OPCIONES PROPFIND>
      Requerir usuario válido
   </LimitExcept>
   Dav svn
   SVNPath / home / svn /

Comprometer el resultado:

Transmitiendo datos de archivo .............................. svn: Error de confirmación
(los detalles siguen):
svn: PONER de
'/!svn/wrk/48583f7d-0e01-410d-8941-33d2ba3574b4/WAP/.../htdocs/images/rt.gif':
Error en la negociación de SSL: error de SSL: analizar tlsext (https: // ...)

Encontré referencias a él aquí: http://code.google.com/p/support/issues/detail?id=1395

indicando que OpenSSL debe compilarse con la extensión TLS, pero en mi caso, no se produce un error al principio, solo en confirmaciones grandes.

¿Algunas ideas? Gracias

No he experimentado este problema, pero pasé un tiempo buscando en Google y descubrí que puede haberse introducido en Apache 2.2.12 o 13. Se sugiere que la degradación a 2.2.11 puede solucionarlo, así como configurar SSLProtocol: ALL + SSLv2 + SSLv3 en su configuración de Apache. Ninguno de los dos parecía definitivo. ¡Buena suerte! Espero que encuentres una solución.

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

ACTUALIZAR

Después de leer el hilo http-dev sobre este problema, archivado en http://www.gossamer-threads.com/lists/apache/dev/375633 , parece que este problema es causado por un error en la biblioteca OpenSSL del lado del cliente en se refiere a cómo se manejan los tickets / ID SSL, lo que explica por qué el error no ocurre de inmediato, sino que demora unos segundos o minutos. Esta resolución se determinó el 2 de noviembre, tres días antes de que saliera OpenSSL 0.9.8l. El subproceso no indica explícitamente si / cuando la corrección se aplicó a OpenSSL, pero creo que es algo que podemos anticipar que se arregle en 0.9.8m, que creo que está cubierto por esta entrada en el registro de cambios m-beta:

*) Se corrige el manejo de reanudación de sesión sin estado. Use initial_ctx al emitir e intentar descifrar tickets en caso de que haya cambiado durante el manejo del nombre del servidor. Utilice una ID de sesión de longitud distinta de cero cuando intente la reanudación de la sesión sin estado: esto permite determinar si se ha producido una reanudación inmediatamente después de recibir el saludo del servidor (varios lugares en OpenSSL asumen esto sutilmente) en lugar de más adelante en el apretón de manos.

POSTE ORIGINAL

Estoy experimentando problemas similares en Apache-2.2.14 en Gentoo. Como referencia, aquí están mis banderas 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

Esto ocurre con cualquier combinación de SSLProtocol con TLSv1incluido

Si ajusto mi SSLProtocolpara eliminar TLSv1, aparece un nuevo 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)

Esto ocurre aproximadamente al mismo tiempo que me encuentro con el error "parse tlsext" en su lugar.

Este problema se debe principalmente al uso de múltiples VirtualHosts con SSL habilitado en Apache httpd 2.2.12 - 2.2.14 y OpenSSL 0.9.8f - 0.9.8l.

El siguiente parche parece resolver el problema para mí.