Especialistas em segurança sugeriram usar o RC4
para remediar a vulnerabilidade do SSL/TLS, que veio à público na semana
passada. Ao contrário do AES, que é usado na maioria dos servidores, o algoritmo de
criptografia de fluxo não usa
o modo Cipher
Block Chaining
(CBC). As implementações CBC em todas as versões acima do SSL3.0/TLS 1.0 são
vuneráveis aos ataques “chosen-plaintext”.
No coração do problema estão os vetores de inicialização, que não são randomizados para cada bloco – os vetores são feitos supostamente para garantir que os blocos idênticos não gerem a mesma cifra – isso permite que os cookies que são transmitidos de forma criptografada sejam determinados muito mais rapidamente com “palpites” do que
com a
força bruta. Entretanto, para que o processo seja bem sucedido, deve-se usar um
ataque Man-in-the-Middle (MitM) para interceptar a conexão do servidor da
vítima e para se comunicar com o servidor no contexto da vítima.
O analista de segurança do Google, Adam Langley,
revelou mais detalhes, como o fato de que o código do JavaScript, que era
objeto de especulação até semana passada, foi injetado no navegador da vítima
pelo iFrame durante o ataque do MitM. O script manda milhares de requisições
SSL feitas sob medida e avalia as respostas. Os pesquisadores de segurança tailandeses,
Thai Duong and Juliano Rizzo, apresentaram a ferramenta BEAST (Browser Exploit
Against SSL/TLS) para automatizar o ataque.
O problema pode ser resolvido ao mudar para o padrão TLS 1.1, que foi adotado em 2006. Nele, os vetores de inicialização são radomizados, o que torna o ataque descrito ineficaz. Entretanto, a mudança é potencialmente problemática, porque nem todos os servidores suportam o padrão.
De acordo com a análise do especialistas de
segurança, Tierry Zoller, o Chrome e o Firefox usam o NSS, que suporta apenas o
TLS 1.0. Por padrão, o Windows Vista, XP, 2000 e Server 2003, assim como o
2008, também são incapazes de suportar o TLS 1.1. Apenas o Windows 7 e o Server
2008 R2 podem usar o TLS 1.1. O Opera 10, por outro lado, trabalha com o TLS
1.2. No entanto, não adianta mudar a configuração do navegador se o servidor não suporta o padrão.
Enquanto
isso, o Google implementou uma correção na versão para desenvolvedores do
Chrome, que foi proposta pelos desenvolvedores da OpenSSL em 2004. A adição de pacotes vazios como medida de
proteção foi implementada pela OpenSSL por algum tempo. No entanto, Zoller disse que a medida não é ativada por
padrão por razões de compatibilidade.
Com informações de The H