“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.