Conexão SSL trava como cliente hello (curl, openssl client, apt-get, wget, tudo)

Question

Eu tive um problema no meu Debian VPS (a xen domU) em relação ao SSL. Ou seja, quase todas as conexões SSL são interrompidas no cliente hello. Por exemplo:

# curl -vI https://graph.facebook.com

• Sobre conectar () à porta 443 do graph.facebook.com (# 0)
• Tentando 66.220.146.48 ... conectado
• Conectado à porta 443 do graph.facebook.com (66.220.146.48) (# 0)
• locais de verificação de certificados definidos com êxito:
• CAfile: nenhum Roteiro: / etc / ssl / certs
• SSLv3, handshake TLS, cliente hello (1):

É o mesmo ao usar o cliente openssl. No entanto, parte do tráfego SSL funciona (por exemplo, link ).

Servidor

#uname -a

Linux server.com 2.6.26-1-xen-amd64 #1 SMP Fri Mar 13 21:39:38 UTC 2009 x86_64 GNU/Linux

No entanto, funciona no meu Dom 0 (o host xen principal).

Apt-get

Eu não consigo nem executar o apt-get update com as fontes de segurança do Debian (trava nos cabeçalhos de leitura)

Abrir SSL

No começo, eu achava que tinha um cliente openssl antigo (0.9.8o-4), já que eu parecia ter um novo no Dom 0 (0.9.8g-15 + lenny8), mas fazendo uma atualização manua no deb do openssl não ajudou.

Abra o cliente SSL

Esta é a saída completa de quando o cliente openssl trava: link

Pensamentos finais

Eu pesquisei a porcaria disso, e não estou indo mais longe. Eu vi problemas com curl, apt-get etc. mas eles são todos específicos relacionados à própria aplicação - não geral para o sistema. Alguma idéia?

    

Answer 1

Depois de algumas conversas com meu provedor de hospedagem, descobriu-se que eles tinham um problema de MTU com as IP Chains que meu DomU estava usando (mas não o Dom0). Eu queria agradecer a todos que me ajudaram no processo, sua ajuda foi inestimável :)

    

Answer 2

Isso é antigo e já foi respondido, mas sofremos o mesmo problema exato e a causa estava relacionada, mas diferente.

A chave era farejar o tráfego em nosso roteador de borda, onde vimos mensagens ICMP para o servidor (GitHub.com) pedindo fragmentação . Isso estava bagunçando a conexão, com retransmissões, ACKs duplicados e assim.

OpacoteICMPtinhaumcampo,MTUofnexthopcomumvalorestranho,1450.Ovalorusualé1500.

Verificamos nosso roteador e uma das interfaces (um túnel Ethernet) tinha esse valor como MTU, então o roteador estava tomando o MTU mínimo de todas as interfaces como próximo salto. Assim que removemos essa interface (não foi usada), o handshake do SSH começou a funcionar novamente.

    

Answer 3

Tente:

 $sudo apt-get --reinstall install openssl libssl0.9.8

    

Answer 4

Soa como um problema com / dev / urandom do convidado ou / dev / random .. ou talvez outro dispositivo. Execute o seu processo de enforcamento sob strace, e veja se ele está pendurado tentando ler.

    

Answer 5

Eu tentaria usar o openssl s_client e dar a ele um arquivo aleatório ("qualquer" arquivo) apenas para verificar se o problema está relacionado ao / dev / random | urandom como Ben disse:

openssl s_client -state -connect graph.facebook.com:443 -rand anyfile

Esteja ciente de que usar um arquivo dessa maneira é muito perigoso em termos de criptografia, portanto, certifique-se de encontrar outra solução antes de colocá-la em produção.