Pesquisadores propõem extensão TLS para detectar certificados SSL não autorizados

Dois pesquisadores de segurança propuseram uma extensão para o protocolo TLS que permitiria aos navegadores detectar e bloquear certificados SSL emitidos de forma fraudulenta.

Chamado TACK, que é a abreviação de Trust Assertions for Certificate Keys, a extensão foi desenvolvida pelos pesquisadores de segurança Trevor Perrin e Moxie Marlinspike e foi submetida à consideração da Internet Engineering Task Force (IETF), o órgão responsável pela TLS, na quarta-feira. O TACK tenta resolver os problemas relacionados à confiança com a infra-estrutura de chave pública que foram destacados pelas violações de segurança do ano passado nas autoridades de certificação (CAs) Comodo e Diginotar.

[Leitura adicional: Como remover malware do seu PC com Windows]

Essas violações resultaram em certificados SSL para domínios de alto perfil como google.com, hotmail.com ou mail.yahoo.com, sendo emitidos de forma fraudulenta. No caso do Diginotar, os certificados foram ainda empregados em ataques ativos contra usuários do Google no Irã.

No momento, os navegadores da Web confiam em mais de 600 organizações de todo o mundo para emitir certificados SSL. Essas organizações são conhecidas como autoridades de certificação e cada uma delas pode emitir tecnicamente um certificado válido para qualquer domínio na Internet.

Várias propostas para melhorar o atual sistema baseado em CA foram apresentadas pela Internet e especialistas em segurança no passado. 12 meses, mas não há consenso sobre qual oferece a melhor solução.

Em novembro de 2011, engenheiros de segurança do Google propuseram uma extensão HTTP chamada "pinagem de chave pública" que permitiria que os sites informassem aos navegadores por um cabeçalho HTTP qual certificado É necessário confiar nas autoridades para emitir certificados SSL para seus nomes de domínio.

Os navegadores devem lembrar (fixar) essas informações e se recusar a estabelecer a conexão se receberem um certificado assinado por uma CA diferente no futuro. Uma implementação mais estática desse sistema já existe no Google Chrome para nomes de domínio específicos, incluindo o

TACK do Google, baseado no mesmo conceito de pinagem de chave pública, mas em vez de fixar chaves públicas de CA em nomes de domínio específicos gerados pelos próprios proprietários do domínio.

Com o TACK, o proprietário do domínio pode gerar um par de chaves privadas e públicas chamadas chaves TACK. A chave privada é usada para assinar a chave pública TLS do servidor, que é usada atualmente pelos navegadores para validar os certificados SSL. A chave pública TACK é então compartilhada com navegadores de conexão e é usada para validar a chave pública TLS assinada pelo TACK

Os navegadores podem fixar uma chave pública TACK em um nome de domínio se o receberem do servidor em várias ocasiões separadas. Se um invasor tentar usar um certificado SSL desonesto para falsificar uma conexão segura com um nome de domínio que já tenha uma chave TACK fixada a ele, o navegador não o autorizará porque a validação do TACK falhará.

Isso cria uma proteção secundária camada, porque além de um certificado SSL obtido com CA, obtido fraudulentamente, um invasor também precisaria da chave TACK privada do proprietário do domínio para realizar um ataque bem-sucedido.

O TACK foi projetado para ser compatível com versões anteriores clientes e servidores que não têm suporte para isso. Em tais situações, a conexão HTTPS é negociada de acordo com o sistema de validação atual baseado em CA.

Esse aspecto é particularmente importante, devido à adoção lenta de novas versões do TLS pelos proprietários do servidor da Web. De acordo com o projeto SSL Pulse da Trustworthy Internet Movement, menos de dois por cento dos principais sites habilitados para HTTPS da Internet suportam TLS 1.1 ou 1.2, as versões mais recentes do protocolo.

A grande maioria dos sites ainda suporta SSL 3.0, o precursor de TLS e TLS versão 1.0, que foi projetado em 1 . Mais de 30% deles ainda suportam SSL 2.0, a primeira versão do protocolo disponível para o público e mais insegura.

Sob essas condições, é difícil imaginar que a TACK se torne amplamente implementada em breve, mesmo que a extensão acabe recebendo aprovação da IETF.