“Erro de SSL analise tlsext” na confirmação grande para SVN via Apache, Gentoo


10

Isso acontece apenas na confirmação grande (resultando em falha na confirmação):

Seção Revelant da configuração do host virtual no Apache

   <LimitExcept GET RELATÓRIO DE OPÇÕES DE PROPFIND>
      Exigir usuário válido
   </LimitExcept>
   Dav svn
   SVNPath / home / svn /

Confirmar resultado:

Transmitindo dados do arquivo .............................. svn: Falha ao confirmar
(detalhes a seguir):
svn: PUT de
'/!svn/wrk/48583f7d-0e01-410d-8941-33d2ba3574b4/WAP/.../htdocs/images/rt.gif':
Falha na negociação do SSL: erro do SSL: analise tlsext (https: // ...)

Encontrei referências a ele aqui: http://code.google.com/p/support/issues/detail?id=1395

afirmando que o OpenSSL deve ser compilado com a extensão TLS, mas no meu caso, ele não apresenta erros no início, apenas em commits grandes.

Alguma ideia? obrigado


existe um ticket do apache httpd bugtracker para esse bug?
— precisa saber é o seguinte

Respostas:


7

Não encontrei esse problema, mas passei um tempo pesquisando e descobri que ele pode ter sido introduzido no Apache 2.2.12 ou 13. Sugere-se que a atualização para o 2.2.11 possa corrigi-lo, além de definir o SSLProtocol - ALL + SSLv2 + SSLv3 na sua configuração do Apache. Nenhum dos dois parecia definitivo. Boa sorte! Espero que encontre uma solução.

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


A adição de SSLProtocol -ALL + SSLv2 + SSLv3 também funcionou para mim.

Pelo que vale, tive o mesmo problema e a adição de SSLProtocol -ALL + SSLv2 + SSLv3, conforme mencionado acima, corrigiu esse problema para mim.
— Adam Carr

Eu estava tendo o mesmo problema ao tentar conectar-me a partir do Ruby 1.9.3. O Ruby 1.9.2 não foi um problema por qualquer motivo. E o erro ocorreu imediatamente ao usar um certificado de cliente. Alterar minha configuração de SSLProtocol all -SSLv2para SSLProtocol ALL -SSLv2 -TLSv1corrigir o problema para mim.
— precisa saber é


5

ATUALIZAR

Depois de ler o encadeamento http-dev sobre esse problema, arquivado em http://www.gossamer-threads.com/lists/apache/dev/375633 , parece que esse problema foi causado por um erro na biblioteca OpenSSL do lado do cliente em diz respeito à forma como os tickets / IDs SSL são tratados, o que explica por que o erro não ocorre imediatamente, mas leva alguns segundos a minutos. Esta resolução foi determinada em 2 de novembro, três dias antes da publicação do OpenSSL 0.9.8l. O encadeamento não indica explicitamente se / quando a correção foi aplicada ao OpenSSL, mas acho que é algo que podemos prever que seja corrigido em 0.9.8m, que acredito ser coberto por essa entrada no registro de alterações m-beta:

*) Correções no tratamento de retomada de sessão sem estado. Use initial_ctx ao emitir e tentar descriptografar tickets, caso ele tenha sido alterado durante o tratamento do nome do servidor. Use um ID de sessão com duração diferente de zero ao tentar reiniciar a sessão sem estado: isso possibilita determinar se ocorreu uma retomada imediatamente após o recebimento do hello do servidor (vários locais no OpenSSL assumem isso sutilmente) em vez de posteriormente no handshake.

POST ORIGINAL

Estou enfrentando problemas semelhantes no Apache-2.2.14 no Gentoo. Para referência, aqui estão meus sinalizadores de 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

Isso ocorre com qualquer combinação de SSLProtocol com TLSv1incluído

Se eu ajustar minha SSLProtocolremoção TLSv1, recebo um novo erro:

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)

Isso ocorre aproximadamente ao mesmo tempo em que eu encontraria o erro "analisar tlsext".


A atualização do meu cliente SVN de 1,6 para 1,7 resolveu o problema "parse tlsext" para mim, apoiando a sugestão de @ gabe-martin-dempesy de que "esse problema é causado por um bug na biblioteca OpenSSL do lado do cliente"
— Jared Beck

0

Esse problema é mais provável devido ao uso de vários VirtualHosts habilitados para SSL no Apache httpd 2.2.12 - 2.2.14 e no OpenSSL 0.9.8f - 0.9.8l.

O patch a seguir parece resolver o problema para mim.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.