Question «Erreur SSL analyse tlsext» sur un grand commit sur SVN via Apache, Gentoo


Cela se produit uniquement sur les grands commit (entraînant un commit échoué):

Section Revelant de la configuration d'hôte virtuel dans Apache

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

Résultat engagé:

Transmission de données de fichier .............................. svn: échec de validation
(les détails suivent):
svn: PUT de
'/!svn/wrk/48583f7d-0e01-410d-8941-33d2ba3574b4/WAP/.../htdocs/images/rt.gif':
La négociation SSL a échoué: Erreur SSL: analyser tlsext (https: // ...)

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

déclarant qu'OpenSSL doit être compilé avec l'extension TLS, mais dans mon cas, il ne commet pas d'erreur au début, mais uniquement sur les grands commits.

Des idées? Merci


10
2017-07-23 07:47


origine


Existe-t-il un ticket Apache httpd bugtracker pour ce bug? - user28271


Réponses:


Je n'ai pas rencontré ce problème, mais j'ai passé un certain temps à chercher sur Google et j'ai découvert qu'il avait peut-être été introduit dans Apache 2.2.12 ou 13. Il est suggéré que le passage à la version 2.2.11 corrige ce problème. 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


7
2017-10-16 01:53



Ajouter SSLProtocol -ALL + SSLv2 + SSLv3 travaillé pour moi aussi.
Pour ce qu'il vaut, j'ai eu le même problème et en ajoutant SSLProtocol -ALL + SSLv2 + SSLv3 comme mentionné ci-dessus résolu ce problème pour moi. - Adam Carr
J'avais ce même problème en essayant de me connecter depuis Ruby 1.9.3. Ruby 1.9.2 n'était pas un problème pour une raison quelconque. Et l'erreur s'est produite immédiatement lors de l'utilisation d'un certificat client. Changer ma configuration de SSLProtocol all -SSLv2 à SSLProtocol ALL -SSLv2 -TLSv1 résolu le problème pour moi. - aNoble
Veuillez noter que SSLv2 est obsolète depuis 1996 - Jared Beck


METTRE À JOUR

Après avoir lu le fil http-dev sur ce problème, archivé à http://www.gossamer-threads.com/lists/apache/dev/375633 , il semble que ce problème soit dû à un bogue de la bibliothèque OpenSSL côté client concernant la gestion des tickets / ID SSL, 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 fil de discussion 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, ce qui, je pense, est couvert par cette entrée dans le journal des modifications de la m-beta:

*) Correction d'une session sans état   reprise de manutention. Utilisez initial_ctx   quand        émettre et tenter de décrypter les tickets au cas où il aurait changé au cours de la        gestion du nom de serveur. Utilisez un identifiant de session de longueur non nulle lorsque   tenter        reprise de session sans état: cela permet de déterminer si        une reprise a eu lieu immédiatement après le serveur de réception   Bonjour        (plusieurs endroits dans OpenSSL le supposent subtilement) au lieu de plus tard dans        la poignée de main.

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 n’importe quelle combinaison de SSLProtocol avec TLSv1 inclus

Si j'ajuste mon SSLProtocol retirer TLSv1, Je reçois 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 où je rencontrais à la place l'erreur "parse tlsext".


5
2018-02-09 18:52



La mise à niveau de mon client SVN de 1.6 à 1.7 a résolu le problème de "parse tlsext", corroborant la suggestion de @ gabe-martin-dempesy selon laquelle "ce problème est provoqué par un bogue de la bibliothèque OpenSSL côté client". - Jared Beck


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

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


0
2018-01-06 17:38