"Erro de SSL analise tlsext" na confirmação grande para SVN via Apache, Gentoo
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>
Confirmar resultado:
Transmitindo dados do arquivo .............................. svn: Falha ao confirmar
(detalhes a seguir):
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.
existe um ticket do apache httpd bugtracker para esse bug?
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.
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.
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.
Observe que o SSLv2 está obsoleto desde 1996
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.
Estou enfrentando problemas semelhantes no Apache-2.2.14 no Gentoo. Para referência, aqui estão meus sinalizadores de USE:
Isso ocorre com qualquer combinação de SSLProtocol com TLSv1incluído
Se eu ajustar minha SSLProtocolremoção TLSv1, recebo um novo erro:
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"
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.