No log de erros do nginx: “SSL_BYTES_TO_CIPHER_LIST: fallback inapropriado”

Question

Recentemente, alteramos nossa configuração do nginx para oferecer suporte a TLSv1.2, além de vários códigos mais seguros. Desde a mudança, nossos logs de erro do nginx foram preenchidos com os seguintes erros:

2015/01/28 23:55:57 [crit] 16898#0: *18712916 SSL_do_handshake() failed (SSL: error:140A1175:SSL routines:SSL_BYTES_TO_CIPHER_LIST:inappropriate fallback) while SSL handshaking, client: ..., server: 0.0.0.0:443

Nossa configuração do nginx é a seguinte:

server {
  root   /var/www/fl/current/public;

  listen              443;
  ssl                 on;
  ssl_certificate     /etc/nginx/ssl/wildcard.pem;
  ssl_certificate_key /etc/nginx/ssl/wildcard.key;
  ssl_session_timeout 5m;
  ssl_session_cache shared:SSL:50m;
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
  ssl_prefer_server_ciphers on;

Recebemos alguns e-mails sobre usuários que não conseguem acessar o site. Um usuário disse que esse é o erro que recebem no Firefox:

Secure Connection Failed

An error occurred during a connection to ******.com. The server rejected the handshake because the client downgraded to a lower TLS version than the server supports. (Error code: ssl_error_inappropriate_fallback_alert)

The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.

Se eu entendi corretamente, o alerta de fallback é uma precaução de segurança quando o cliente está usando uma versão inferior do TLS do que ele e o servidor suportam. Esse erro parece fazer muito sentido, já que agora suportamos uma versão de protocolo mais alta. O que não entendo é por que essa alteração causaria problemas para alguns usuários ao se conectarem ao nosso site. Isso é uma falha em nossa configuração ou no navegador deles?

Agora pontuamos um 'A' no teste de servidor SSL da Qualys, por isso hesito em voltar à nossa configuração antiga.

    

Answer 1

Os navegadores geralmente fazem um handshake SSLv23. Com esse aperto de mão, eles anunciam a melhor versão de protocolo que suportam (na maioria das vezes TLS1.2 hoje), mas não restringem o servidor a essa versão. Assim, um servidor, que possui uma pilha TLS adequadamente implementada e configurada, mas suporta apenas TLS1.0, simplesmente responderá com TLS1.0 e a conexão será bem-sucedida na primeira tentativa.

Mas, há algumas pilhas ou configurações incorretas de TLS ou algumas middleboxes ruins (balanceador de carga, etc.) no lado do servidor, que causam falha no handshake SSLv23. Nesses casos, os navegadores fazem downgrade do protocolo usado no handshake, ou seja, tentam com um handshake TLS1.0 explícito seguido por um handshake SSL3.0 explícito (alguns navegadores já desabilitaram o SSL3.0 e, portanto, não tentaram isso).

Os navegadores mais recentes usarão a pseudo-cifra TLS_FALLBACK_SCSV se fizerem essa conexão desatualizada. Se o servidor capaz de TLS_FALLBACK_SCSV detectar uma conexão desatualizada com uma versão de protocolo mais baixa, ele suportará (por exemplo, downgrade usa TLS1.0, mas o servidor suporta TLS1.2) do que pressupõe que um ataque semelhante ao POODLE ocorre e fechará a conexão.

Mas por que um cliente pode fazer o downgrade em primeiro lugar ao entrar em contato com o servidor?

• Você pode ter um balanceador de carga quebrado na frente, o que faz com que você receba pedidos desnecessários.
• Seu servidor ou algum dispositivo anti-DOS na frente pode simplesmente fechar as conexões em alta carga antes que o handshake SSL seja concluído. Nesse caso, o navegador assumirá um problema de protocolo e tentará novamente com uma versão desatualizada.
• Qualquer outro tipo de problema, como falta de memória, etc., que pode causar fechamento aleatório no handshake SSL.

Answer 2

A alteração 318904 teve um conjunto de patches relacionado carregado (por BBlack): não-crítico para o handshake do cliente SSL_R_VERSION_TOO_LOW

link

link