Últimas notícias

Fique informado
As falhas recentes do SSL/TLS, quem é o culpado?

As falhas recentes do SSL/TLS, quem é o culpado?

1 de abril de 2015

Spotlight

Doc9 lança Guia Prático de Prompts para ChatGPT no Jurídico: Como Maximizar a Eficiência com a Inteligência Artificial

Para obter os melhores resultados com o ChatGPT no contexto jurídico, siga as dicas importantes do Guia Prático de Prompts da doc9.

28 de maio de 2024

Governo Federal apoia Rio Grande do Sul na emissão 2ª via da Carteira de Identidade Nacional

O mutirão coordenado pelo Governo do RS começou nos abrigos de Porto Alegre. Expedição da segunda via será imediata

20 de maio de 2024

O cerco à privacidade infantil

Já foi mais fácil ser criança, no tempo em que

26 de março de 2015

Não faça da criptografia uma arma

Aproveitando o bordão exaurido, mas “a vítima pode ser a

20 de março de 2015

Governos e o enfraquecimento criptográfico – tiro no pé

Acabamos de sofrer mais um ataque contra o SSL, chamado

5 de março de 2015

A crise: Governo vs. Criptografia vs. Internacionalização

Então você lê a transcrição de um evento de segurança onde

26 de fevereiro de 2015
Sergio Leal - Colunista CryptoID

Sergio Leal – Colunista CryptoID

Muitos questionam a eficiência e segurança do SSL/TLS como ferramenta de segurança na Internet, a luz das muitas falhas registradas nos últimos meses. O que realmente está acontecendo com ele, e como isso nos afeta no dia a dia?

Do ponto de vista do usuário final o SSL/TLS é uma obra de arte. Digo isso porque se conseguiu criar um protocolo criptográfico eficaz, que funciona de maneira transparente, com alto nível de segurança e alto volume de adoção na Internet. Isso é quase uma utopia.

Mas de um jeito ou outro, o SSL/TLS atingiu seus objetivos. Imagine como seria uma Internet sem túneis criptográficos ou dependendo de intervenção manual para chegarmos de maneira segura aos sites de banco e aos e-commerces? Jamais teríamos chegado onde estamos hoje.

Downgrade Dance

O principal mecanismo explorado nessas falhas é o “downgrade dance”. Ele foi criado para oferecer uma operação transparente para o usuário mesmo que ele tenha um navegador mais antigo e não suporte os protocolos mais seguros. A regra é simples, será escolhida a melhor versão de protocolo suportada pelos envolvidos (cliente e servidor). Assim, se você deseja atacar um servidor basta dizer que suporta apenas uma versão bem antiga e insegura do protocolo.

Qual a solução? Oferecer suporte apenas a um conjunto de algoritmos seguros, deixando de fora aqueles que não possam atender esse padrão.

Veja algumas “falhas” abaixo.

POODLE

É um ataque que força o servidor a operar no modo SSL v3, que é um modo antigo, obsoleto e inseguro. Isso permite ao hacker roubar cookies, tokens de autenticação e coisas do tipo.

FREAK

É um problema relacionado às antigas “cifras de exportação” que os produtos americanos precisavam incorporar. O Governos Americano esperava usar esses recursos para espionar os servidores de outros países, mas isso deixou de ser necessário em 2000, ainda assim o código permaneceu lá.

Descobriu-se agora que é possível forçar um “fallback” para usar esse código inseguro. E o mais engraçado é ver isso afetando os sites da Casa Branca, FBI e NSA. O feitiço virando contra o feiticeiro.

Para não ser afetado, bastava configurar no seu servidor que essa opção de configuração não estaria disponível, como no exemplo do Apache: “SSLCipherSuite !EXPORT”.

RC4
O último ataque se baseia em forçar o uso do RC4, a “stream chipher” mais popular no mundo. É usado para proteger até 30% do tráfego SSL hoje. O ataque se baseia em um problema do RC4 publicado em 2001. O ideal é desabilitar o uso do RC4 em qualquer circunstância em uma conexão SSL/TLS.

Quem é o culpado?

A configuração do servidor deveria limitar-se às versões mais novas e fortes do protocolo e das cifras criptográficas. Todo protocolo que utiliza um mecanismo de “fallback” – como o downgrade dance – trás um conjunto de riscos que devem ser monitorado, forçando uma re-análise periódica de suas configurações. Ao longo do tempo, as configurações que eram consideradas seguras acabam sendo ‘quebradas’ e substituídas por novas opções.

Assim, todos os envolvidos deveriam preocupar-se em desabilitar as configurações ‘quebradas’ e manter apenas aquelas consideradas seguras.

Se alguém tentasse, maliciosamente ou não, usar o “downgrade dance” como ferramenta de ataque, tentando forçar uma sessão insegura, o servidor não deveria aceitar a escolha e abortar a conexão.

Quais cifras devem ser ofertadas?

Parte da culpa fica nos ombros de quem comercializa o produto. Esse deveria se preocupar em ter uma instalação padrão minimamente segura. Por outro lado, o administrador deveria ter conhecimento (e capricho) suficiente para rever as configurações e corrigí-la.

Nerd Stuff 🙂

Conecte com seu navegador no Google e veja a cifra simétrica usada: AES GCM 128 bits.

Se você tem o Openssl tente o comando abaixo. Se não baixe daqui a versão Windows, pois Linux e Mac já tem por padrão.

openssl s_client -connect  “www.google.com:443

E veja a cifra usada pelo Google:

SSL-Session:
Protocol  : TLSv1
Cipher    : RC4-SHA

Sérgio Leal 

  • Ativista de longa data no meio da criptografia e certificação digital.
  • Trabalha com criptografia e certificação Digital desde o início da década de 90, tendo ocupado posições de destaque em empresas lideres em seu segmento como Modulo e CertiSign.
  • Criador da ‘ittru’: Primeira solução de certificação digital mobile no mundo.
  • Bacharel em Ciências da Computação pea UERJ desde 1997.
  • Certificações:
    – Project Management Professional (desde 2007)
    – TOGAF 9.1 Certified
    – Oracle Certified Expert, Java EE 6 (Web Services Developer, Enterprise JavaBeans Developer)
  • Sérgio Leal  é colunista e membro do conselho editorial do CryptoID.