"SSL error parse tlsext" lors d'un gros commit vers SVN via Apache, Gentoo

Cela ne se produit que sur une grande validation (entraînant un échec de validation):

Section révélée de la configuration de l'hôte virtuel dans Apache

   <LimitExcept GET PROPFIND OPTIONS REPORT>
      Exiger un utilisateur valide
   </LimitExcept>
   Dav svn
   SVNPath / home / svn /

Résultat du commit:

Transmission des données du fichier .............................. svn: échec de la validation
(les détails suivent):
svn: PUT de
«/!svn/wrk/48583f7d-0e01-410d-8941-33d2ba3574b4/WAP/.../htdocs/images/rt.gif»:
Échec de la négociation SSL: erreur SSL: analyser tlsext (https: // ...)

J'ai trouvé des références ici: http://code.google.com/p/support/issues/detail?id=1395

indiquant qu'OpenSSL doit être compilé avec l'extension TLS, mais dans mon cas, il ne génère pas d'erreur au début, juste sur les grands commits.

Des idées? Merci

Je n'ai pas rencontré ce problème, mais j'ai passé un certain temps à faire des recherches sur Google et j'ai constaté qu'il pouvait avoir été introduit dans Apache 2.2.12 ou 13. Il est suggéré que la rétrogradation vers 2.2.11 puisse le résoudre, ainsi que la configuration de SSLProtocol - ALL + SSLv2 + SSLv3 dans votre configuration Apache. Aucun des deux ne semblait définitif. Bonne chance! J'espère que vous trouverez une solution.

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

METTRE À JOUR

Après avoir lu le fil http-dev sur ce problème, archivé sur http://www.gossamer-threads.com/lists/apache/dev/375633 , il semble que ce problème soit dû à un bogue dans la bibliothèque OpenSSL côté client dans en ce qui concerne la façon dont les tickets / identifiants SSL sont traités, ce qui explique pourquoi l'erreur ne se produit pas immédiatement, mais prend quelques secondes à quelques minutes. Cette résolution a été déterminée le 2 novembre, trois jours avant la sortie d'OpenSSL 0.9.8l. Le thread n'indique pas explicitement si / quand le correctif a été appliqué à OpenSSL, mais je pense que c'est quelque chose que nous pouvons anticiper d'être corrigé dans 0.9.8m, qui je crois est couvert par cette entrée dans le changelog m-beta:

*) Correction de la gestion de la reprise de session sans état. Utilisez initial_ctx lors de l'émission et de la tentative de décryptage des tickets au cas où il aurait changé pendant la gestion du nom de serveur. Utilisez un ID de session de longueur non nulle lorsque vous tentez une reprise de session sans état: cela permet de déterminer si une reprise a eu lieu immédiatement après la réception du bonjour du serveur (plusieurs endroits dans OpenSSL le supposent subtilement) au lieu de plus tard dans la prise de contact.

POSTE ORIGINAL

Je rencontre des problèmes similaires sur Apache-2.2.14 sur Gentoo. Pour référence, voici mes drapeaux 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

Cela se produit avec toute combinaison de SSLProtocol avec TLSv1inclus

Si j'ajuste mon SSLProtocolpour supprimer TLSv1, j'obtiens une nouvelle erreur:

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)

Cela se produit à peu près au même moment que je rencontrerais à la place l'erreur "parse tlsext".

Ce problème est très probablement dû à l'utilisation de plusieurs VirtualHosts SSL dans Apache httpd 2.2.12 - 2.2.14 et OpenSSL 0.9.8f - 0.9.8l.

Le patch suivant semble résoudre le problème pour moi.