A fragilidade na relação de confiança entre navegadores e autoridades certificadoras é um possível problema para o SSL.
Altieres Rohr | 08/01/2009 - 16h22
Quem nunca leu um guia de segurança recomendando atenção ao famoso “cadeado” no navegador web? O que dá a essa dica seu valor é uma cadeia de confiança. Mas, por mais que tenha sido repetida, poucos sabem como funciona a segurança SSL, cuja única representação ao usuário se dá por meio do cadeado de segurança em páginas ‘https’. Os internautas não sabem que seus navegadores estão confiando em uma AC — Autoridade Certificadora — nem por que essa AC merece confiança.
Informações divulgadas nas últimas semanas mostraram que algumas ACs não estão cumprindo com sua parte do “acordo”, deixando brechas para que toda a cadeia de confiança seja quebrada. Mesmo assim, os desenvolvedores de navegadores — responsáveis por escolher quais ACs merecem confiança — viram-se desprovidos de qualquer força, dado a quantidade de sites que apresentariam problemas se decidissem deixar de confiar nas ACs afetadas.
O SSL (”Secure Sockets Layer”) tem dois objetivos. O primeiro deles é garantir que o site que você está visitando é realmente quem diz ser. Ou seja, ele busca impedir os criminosos de redirecionar os usuários a websites falsos, não controlados pelos verdadeiros donos do domínio. Para realizar um ataque desse tipo, o invasor teria que comprometer algum sistema do provedor do internauta. A brecha do DNS possibilitava isso, por exemplo.
O outro objetivo é criptografar, ou “embaralhar” a transmissão. Dessa maneira, se o criminoso tiver o controle sobre qualquer sistema pelo qual a conexão passar, ele não conseguirá ler o conteúdo. As senhas e dados estarão protegidos contra “grampos”.
A parte da criptografia é fácil. Qualquer certificado1, mesmo os certificados expirados, inválidos ou criados pelo próprio dono do site teriam esse efeito. O problema é a garantia de que o site é mesmo aquele que você está visitando. Como qualquer um pode emitir um certificado garantindo a autenticidade do site, foi preciso elaborar um sistema que validasse os certificados.
Criou-se então as chamadas “Certificate Authorities” (CA) ou Autoridades Certificadoras (AC). O dono de um site, após criar o certificado, envia-o para uma CA, que o assina e garante sua validade. É claro que, antes da assinar o certificado, a AC deveria verificar que quem gerou aquele certificado é realmente o dono do site.
O navegador web, por sua vez, inclui o certificado (chave pública) das ACs. Toda vez que um certificado legítimo, assinado e garantido por uma AC for enviado por um site, o navegador pode atestar sua veracidade com base na chave pública instalada. Isso também garante que a checagem dos certificados não dependa da internet, tornando-a mais segura. Se o certificado não for assinado por um AC confiada, uma mensagem de erro será exibida.
Em outras palavras, o navegador confia na segurança da AC e por isso considera o certificado válido. Se a chave usada por um site for assinado por uma AC desconhecida, o navegador irá exibir um erro. Isso pode ser facilmente percebido hoje no site da ICP-Brasil: enquanto o Firefox exibe um aviso de “certificado não confiado”, o Internet Explorer 7 o abre sem problemas. Isso porque o certificado AC da ICP-Brasil, que assinou a chave usada pelo site, já está instalado no IE por padrão, mas não no Firefox.
No final de 2008, dois eventos abalaram a credibilidade de algumas ACs. Primeiro, um especialista em segurança ligado à StartSSL, uma AC, descobriu que um revendedor de outra AC, a Comodo, não estava verificando as credenciais do solicitante do certificado. Por isso, ele conseguiu obter um certificado para o site “mozilla.com” sem ter qualquer ligação com a Mozilla.
A verificação de titularidade de domínio é uma das tarefas mais básicas que uma AC deve realizar, porém não há incentivo econômico direto para isso. Sempre que a emissão de um certificado é negada, a empresa deixa de ganhar dinheiro. O que incentiva as empresas a emitir apenas certificados seguros é a ameaça de serem retiradas da lista de empresas confiadas pelos navegadores: sem estarem nessa lista, nenhum certificado tem valor e elas ficam impedidas de continuar seu negócio.
Uma semana depois dessa revelação, vários pesquisadores de segurança divulgaram um experimento técnico e complicado que provou a vulnerabilidade das assinaturas feitas com a tecnologia MD5. Eles descobriram que várias ACs ainda utilizavam MD5 para assinar certificados, dentre elas a RapidSSL, associada à VeriSign, a maior empresa do ramo.
A VeriSign “reclamou” que os pesquisadores não entraram em contato para avisá-los do problema. A questão, no entanto, é que ataques de “colisão” no MD5 — como o usado no experimento — são considerados possíveis desde 2004. As empresas tiveram praticamente quatro anos para migrar para uma tecnologia mais segura, como o SHA-1 e suas variações, mas não o fizeram.
O que se percebe é uma inércia perigosa e inaceitável para empresas que lidam com uma parte tão importante da infraestrutura da internet.
Apesar de terem errado em aspectos básicos da segurança de sua operação, as duas ACs não foram retiradas da lista de entidades confiadas pelos navegadores. Por quê? Porque muitos sites legítimos iriam parar de funcionar.
Nesse momento, vê-se que as relações de incentivos foram desestabilizadas. As ACs não podem emitir qualquer certificado que quiserem porque precisam da confiança dos navegadores. Mas, por serem grandes e responsáveis por muitos sites, os navegadores temem causar problemas demais caso venham a tirar as empresas afetadas pelos problemas da lista de ACs confiadas.
Ficam no ar as perguntas: quão ruim uma AC pode ser? Quantos erros elas podem cometer até que uma modificação na lista de ACs confiadas seja considerada? Será que as empresas envolvidas fossem menores a reação teria sido a mesma?
O mais triste, talvez, é que poucos saibam disso tudo, mas mesmo assim confiam nos cadeados de segurança — pelo menos quando não clicam direto em qualquer mensagem que aparece na tela.
Altieres Rohr é editor-chefe e fundador da Linha Defensiva. Começou a acompanhar o mundo da segurança em 2004, quando se tornou responsável pelas áreas relacionadas ao assunto no Fórum do Clube do Hardware. Além de editor da Linha Defensiva, é atualmente é membro da Aliança dos Profissionais de Análise de Segurança e colunista da editoria de Tecnologia e Games do G1 (Globo.com).