
Encontramos problemas muito estranhos ao conectar-se com openssl ou curl a um de nossos servidores, do Ubuntu 14.04
Executando:
openssl s_client -connect ms.icometrix.com:443
dá:
CONNECTED(00000003)
140557262718624:error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert
internal error:s23_clnt.c:770:
Um erro semelhante ao executar:
curl https://ms.icometrix.com
curl: (35) error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert
internal error
Saída da versão do openssl (no cliente/servidor):
OpenSSL 1.0.1f 6 Jan 2014
Saída de openssl de dpkg -l openssl:
1.0.1f-1ubuntu2
O engraçado é que o problema desaparece ao conectar-se com outras versões do Openssl:
- De um Mac, OpenSSL 0.9.8zd 8 de janeiro de 2015, tudo ok
- De centos, OpenSSL 1.0.1e-fips 11 de fevereiro de 2013, tudo ok
- Última versão estável no Ubuntu 14.04, OpenSSL 1.0.2d 9 de julho de 2015, tudo ok.
Do lado do servidor, não vemos nada de estranho. O problema começou quando desabilitamos o SSL3 em nossas máquinas.
Pode haver um problema com a construção do apt-get?
Também testamos outras versões, a proposta pelo apt-cache showpkg, mas o problema permanece...
Responder1
Isto parece ser um problema com o suporte ECDH entre cliente e servidor. Se você excluir todas as cifras ECDH, funcionará:
openssl s_client -connect ms.icometrix.com:443 -cipher 'DEFAULT:!ECDH'
Meu palpite é que o servidor falha em algumas das 25 curvas ECC oferecidas pelo cliente. Os navegadores oferecem apenas algumas curvas. O OpenSSL 0.9.8 ainda não oferece suporte a nenhum ECC e o RedHat/CentOS tem um histórico de desabilitar o ECC por padrão por motivos de patente. Não sei porque o OpenSSL 1.0.2 funciona, pois não tenho acesso a esta versão.
Observe que fornecer a versão OpenSSL geralmente não é suficiente porque todas as distribuições mantêm versões mais antigas, mas adicionam patches de segurança. Em vez disso, verifique dpkg -l openssl
qual fornece 1.0.1f-1ubuntu2.15 no meu sistema.