"Errore di analisi SSL tlsext" su commit di grandi dimensioni in SVN tramite Apache, Gentoo

10

Ciò accade solo su commit di grandi dimensioni (con conseguente commit non riuscito):

Sezione Revelant dalla configurazione dell'host virtuale in Apache

   <LimitExcept OTTIENI RAPPORTO OPZIONI PROPFIND>
      Richiede un utente valido
   </ LimitExcept>
   Dav svn
   SVNPath / home / svn /

Risultato del commit:

Trasmissione dati file .............................. svn: commit fallito
(i dettagli seguono):
svn: PUT di
'/!Svn/wrk/48583f7d-0e01-410d-8941-33d2ba3574b4/WAP/.../htdocs/images/rt.gif':
Negoziazione SSL non riuscita: errore SSL: parse tlsext (https: // ...)

Ho trovato riferimenti qui: http://code.google.com/p/support/issues/detail?id=1395

affermando che OpenSSL dovrebbe essere compilato con l'estensione TLS, ma nel mio caso, non si risolve in errore all'inizio, solo su commit di grandi dimensioni.

Qualche idea? Grazie

apache-2.2 svn gentoo

— Karolis T.
fonte

esiste un ticket bugtracker httpd apache per questo bug?

— user28271

7

Non ho riscontrato questo problema, ma ho passato un po 'di tempo a cercare su google e ho scoperto che potrebbe essere stato introdotto in Apache 2.2.12 o 13. Si suggerisce che il downgrade a 2.2.11 possa risolverlo, così come impostare SSLProtocol - ALL + SSLv2 + SSLv3 nella configurazione di Apache. Nessuno dei due sembrava definitivo. In bocca al lupo! Spero che tu trovi una soluzione.

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

— Jeff Snider
fonte

L'aggiunta di SSLProtocol -ALL + SSLv2 + SSLv3 ha funzionato anche per me.

Per quello che vale, ho avuto lo stesso problema e l'aggiunta di SSLProtocol -ALL + SSLv2 + SSLv3 come menzionato sopra ha risolto questo problema per me.

— Adam Carr,

Stavo riscontrando lo stesso problema nel tentativo di connettermi da Ruby 1.9.3. Ruby 1.9.2 non è stato un problema per nessun motivo. E l'errore si è verificato immediatamente quando si utilizza un certificato client. Cambiare il mio config dal SSLProtocol all -SSLv2al SSLProtocol ALL -SSLv2 -TLSv1risolto il problema per me.

— aNoble

1

Si noti che SSLv2 è stato deprecato dal 1996

— Jared Beck il

5

AGGIORNARE

Dopo aver letto il thread http-dev su questo problema, archiviato su http://www.gossamer-threads.com/lists/apache/dev/375633 , sembra che questo problema sia causato da un bug nella libreria OpenSSL sul lato client in per quanto riguarda la gestione dei ticket / ID SSL, il che spiega perché l'errore non si verifica immediatamente, ma richiede alcuni secondi o minuti. Questa risoluzione è stata determinata il 2 novembre, tre giorni prima dell'uscita di OpenSSL 0.9.8l. Il thread non afferma esplicitamente se / quando la correzione è stata applicata a OpenSSL, ma penso che sia qualcosa che possiamo prevedere di essere riparato in 0.9.8m, che credo sia coperto da questa voce nel log delle modifiche m-beta:

*) Correzioni per la gestione della ripresa della sessione senza stato. Utilizzare initial_ctx durante l'emissione e il tentativo di decrittografare i ticket nel caso in cui sia cambiato durante la gestione del nomeserver. Usa un ID di sessione di durata diversa da zero quando tenti di riprendere la sessione senza stato: questo rende possibile determinare se si è verificata una ripresa immediatamente dopo aver ricevuto il ciao del server (diversi punti in OpenSSL lo assumono sottilmente) anziché successivamente nell'handshake.

POSTO ORIGINALE

Riscontro problemi simili su Apache-2.2.14 su Gentoo. Per riferimento, ecco i miei flag 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

Ciò si verifica con qualsiasi combinazione di SSLProtocol con TLSv1incluso

Se aggiusto il mio SSLProtocolper rimuovere TLSv1, ottengo un nuovo errore:

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)

Ciò si verifica approssimativamente nello stesso momento in cui avrei riscontrato l'errore "parse tlsext".

— Gabe Martin-Dempesy
fonte

L'aggiornamento del mio client SVN dalla 1.6 alla 1.7 ha risolto il problema "parse tlsext", supportando il suggerimento di @ gabe-martin-dempesy che "questo problema è causato da un bug nella libreria OpenSSL sul lato client"

— Jared Beck,

0

Questo problema è più probabile a causa dell'utilizzo di più VirtualHosts abilitati per SSL in Apache httpd 2.2.12 - 2.2.14 e OpenSSL 0.9.8f - 0.9.8l.

La seguente patch sembra risolvere il problema per me.