Prezados amigos, sei que essa polêmica está atiçando a curiosidade de muitos. Vou fazer apenas algumas conjecturas a respeito do tema e lançar outras questões para estimular ainda mais a curiosidade de vocês.
Sobre a quebra do SSL/TLS, quem frequentou alguma turma comigo desde 2011 até hoje e puxar pela memória deve se lembrar que venho comentando e reiterando a insegurança das versões do TLS anteriores à 1.1. Na verdade, desde 2004 uma vulnerabilidade que poderia afetar implementações práticas inadequadas do modo de operação CBC é conhecida. Vou tentar especificar isso um pouco melhor.
Há duas maneiras básicas para se usar o CBC em um protocolo como o SSL ou o TLS, onde os arquivos ou mensagens trocadas entre um cliente e um servidor se comportam como um fluxo de bytes:
1) pode-se tratar cada mensagem como se fosse independente, gerar randomicante um novo vetor de inicialização (IV) e criptografar a mensagem seguinte até o fim do fluxo;
2) pode-se tratar as mensagens como se fossem concatenadas em um único objeto grande e apenas manter o estado CBC entre elas, ou seja, o IV para a próxima mensagem é o último bloco cifrado da mensagem anterior.
O SSLv3 e o TLS 1.0, por exemplo, empregam a segunda abordagem, que é reconhecidamente insegura.
Em setembro de 2011 foi apresentada por Juliano Rizzo e Thai Duong uma ferramenta chamada BEAST (Browser Exploit Against SSL/TLS) num congresso em Buenos Aires. Ela representava uma prova de conceito sobre a exploração da vulnerabilidade acima citada. Segue abaixo um link contendo um vídeo demonstrativo dela em ação.
A partir daí, deu-se início a uma correria frenética dos administradores de redes para reconfigurarem seus servidores Web. A ideia era que eles utilizassem o RC4-128 ao invés de qualquer cifra de bloco, haja vista que o problema não residia em que algoritmo de bloco seria escolhido pelo SSL/TLS, mas no próprio modo de operação. A despeito de boa parte das conexões seguras hoje fazerem uso de versões posteriores ao TLS 1.0, boa parte ainda usa o RC4, fugindo talvez de qualquer nova surpresa como a anterior.
Toda essa discussão serve para dizer o seguinte: seria essa a única vulnerabilidade do SSL/TLS? Como o Thiago Arreguy bem destacou, há tempos comento em sala que as Criptoanálise Linear e Diferencial, publicadas em artigos acadêmicos no início da década de 1990, já eram conhecidas dos americanos quando da homologação do DES em 1977, ou seja, mais do que uma década antes do restante do mundo.
Fato é que isso tudo pode ser apenas a pontinha de um imenso iceberg. Antes da prova da PF, cheguei a comentar em sala que se eu fizesse uma questão discursiva para aquela prova, iria colocar uma captura contendo em hexadecimal um covert channel nas identificações dos pacotes, dentro de seus cabeçalhos. Deixando de lado toda a paranoia de uma possível questão assim, o que impede que isso já esteja ocorrendo com equipamentos que não são de fabricação nacional?
Aliás, ontem mesmo li um artigo que me chamou a atenção para uma suspeita interessantíssima. A Apple acabou de lançar um IPhone com identificação biométrica. Como discuti numa das questões do simulado para a PF que organizamos pelo Dominando TI, esse tipo de informação deveria ter proteção contra replicação de modo similar ao que ocorre com as senhas. O que a Apple usa para essa proteção? Mais que isso: o que a impediria de, por trás dessa estratégia aparentemente genial, repassar para a NSA um imenso banco de identificações biométricas dos usuários do IPhone?
Enfim...
Diante de tudo isso, só o que posso lhes dizer é que cada dia mais Segurança da Informação passará a fazer ainda mais parte do cotidiano da vida das pessoas. Aliás, alguém duvida de que ela venha a ser ainda mais cobrada em provas objetivas e como tema de discursivas?
Voltemos aos estudos. :)
Grande abraço a todos,